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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

The present document is part 2 of a multi-part deliverable covering the Test specification for the Host Controller 
Interface (HCI), as identified below: 

Parti: "Terminal features"; 

Part 2: "UICC features"; 

Part 3: "Host Controller features". 



Introduction 



The present document defines test cases for the UICC relating to the Host Controller Interface (HCI) as specified in 
TS 102 622 [1]. 

The aim of the present document is to ensure interoperability between the terminal and the UICC independently of the 
respective manufacturer, card issuer or operator. 
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Scope 



The present document covers the minimum characteristics which are considered necessary for the UICC in order to 
provide compliance to TS 102 622 [1]. 

The present document specifies the test cases for: 

• the HCI core as described in the first part of TS 102 622 [1]; 

• the contactless platform as described in the second part of TS 102 622 [1]. 

Test cases for the terminal relating to TS 102 622 [1] and test cases for the Single Wire Protocol (SWP) covering both 
terminal and UICC are out of scope of the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version 
of that document in the same Release as the present document. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 622: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Host Controller 

Interface (HCI)". 

[2] ETSI TS 102 613: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Pait 1: Physical 

and data link layer characteristics". 

[3] ISO/lEC 18092: "Information technology - Telecommunications and information exchange 

between systems - Near Field Communication - Interface and Protocol (NFCIP-1)". 

[4] ISO/lEC 14443-3: "Identification cards — Contactless integrated circuit(s) cards — Proximity cards 

— Part 3: Initialization and anticolhsion" . 

[5] ISO/lEC 14443-4: "Identification cards — Contactless integrated circuit cards — Proximity cards — 

Part 4: Transmission Protocol". 

[6] ISO/lEC 9646-7: "Information technology — Open Systems Interconnection — Conformance 

testing methodology and framework — Part 7: Implementation Conformance Statements". 

[7] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics". 

[8] ETSI TS 102 600: "Smart Cards; UICC-Terminal interface; Characteristics of the USB interface". 
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2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not applicable. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 622 [1] and the following apply: 

allowed error response code: response code which is not ANY_OK and which is allowed for the referenced command 
as specified in TS 102 622 [1] 

non-occurrence RQ: RQ which has been extracted from TS 102 622 [1], but which indicates a situation which should 
never occur 

NOTE: The consequence is that such RQs cannot be explicitly tested. 

user: any logical or physical entity which controls the test equipment in a way that it is able to trigger activities of the 
DUT 

3.2 Symbols 

For the purposes of the present document, the symbols given in TS 102 622 [1] and the following apply: 

PIPEq the static pipe connected to the link management gate of the device under test. 

PIPEj the static pipe connected to the administration gate of the device under test. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 622 [1] and the following apply: 

ATQA Answer To reQuest of type A 

ATQB Answer To reQuest of type B 

CLT ContactLess Tunnelling 

DUT Device Under Test 

FFS For Further Study 

FWI Frame Waiting time Integer 

HCI Host Controller Interface 

HCS Host Controller Simulator 

HUT Host Under Test 

ICRx Initial Condition Requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

PICC Proximity Integrated Circuit Card 

PUPI Pseudo-Unique PICC Identifier 

RFU Reserved for Future Use 

RO Read-Only 

RQ conformance Requirement 

RW Read-Write 

SAK Select AcKnowledge 

SFGT Start-up Frame Guard Time 
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SRx Static Requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 
TRx Trigger Requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 
WO Write-Only 

3.4 Void 

Content of this clause has been moved to clause 3 A. 



3A Formats 

3A.1 Format of the table of optional features 

The columns in table 4. 1 have the following meaning. 



Column 


Meaning 


Option 


The optional feature supported or not by tlie DUT. 


Status 


See clause 3.4.3. 


Support 


The support columns shall be filled in by the supplier of the implementation. The following common 
notations, defined in ISO/IEC 9646-7 [6], are used for the support column in table 4.1 . 
Y or y supported by the implementation. 
N or n not supported by the implementation. 

N/A, n/a or - no answer required (allowed only if the status is N/A, directly or after evaluation of a 
conditional status). 


IVInemonic 


The mnemonic column contains mnemonic identifiers for each item. 



3A.2 Format of the applicability table 

The applicability of every test in table 4.2 is formally expressed by the use of Boolean expression defined in the 
following clause. 

The columns in table 4.2 have the following meaning. 



Column 


Meaning 


Clause 


The "Clause" column identifies the clause containing the test case referenced in the "Test case number 
and description" column. 


Test case 
number and 
description 


The "Test case number and description" column gives a reference to the test case number (along with 
the corresponding description) detailed in the present document and required to validate the DUT. 


Release 


The "Release" column gives the Release applicable and onwards, for the corresponding test case. 


Execution 
requirements 


The usage of the "Execution requirements" column is described in clause 4.5.2. 


Rel-x UICC 


For a given Release, the corresponding "Rel-x UICC" column lists the tests required for a DUT to be 
declared compliant to this Release. 


Support 


The "Support" column is blank in the proforma, and shall be completed by the manufacturer in respect of 
each particular requirement to indicate the choices, which have been made in the implementation. 
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3A.3 Status and Notations 



The "Rel-x" columns show the status of the entries as follows: 

The following notations, defined in ISO/IEC 9646-7 [6], are used for the status column: 



mandatory - the capability is required to be supported. 

optional - the capability may be supported or not. 

not applicable - in the given context, it is impossible to use the capability. 

prohibited (excluded) - there is a requirement not to use this capability in the given context. 

qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 
identifies an unique group of related optional items and the logic of their selection which is 
defined immediately following the table. 

conditional - the requirement on the capability ("M", "O", "X" or "N/A") depends on the support 
of other optional or conditional items, "i" is an integer identifying an unique conditional status 
expression which is defined immediately following the table. For nested conditional expressions, 
the syntax "IF ... THEN (IF ... THEN ... ELSE...) ELSE ..." shall be used to avoid ambiguities. 

References to items 

For each possible item answer (answer in the support column) there exists a unique reference, used, for example, in the 
conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item 
number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters 
(a, b, etc.), respectively. 



M 
O 

N/A 

X 

O.i 

Ci 



EXAMPLE: 



4. 1/4 is the reference to the answer of item 4 in table 4. 1 . 



3A.4 Format of the conformance requirements tables 

The conformance requirements tables contained in the present document have the following format and meaning: 



Column 
Status 



Meaning 



Mandatory 



This mandatory column contains the conformance requirement number (e.g. RQ3). 



Optional 



This optional column is present when the containing clause sources conformance requirements from 
multiple clauses in the core specification. In this case, the cells in this column indicate the specific clause 
from the core specification from which the conformance requirement was sourced. 
If the conformance requirements are sourced from a single clause in the core specification, this column 
is not present. 



Optional 



This optional column is present when the table contains conformance requirements which are applicable 
to only a subset of the releases which are covered by the present document. In this case, the content of 
the cells indicates the release(s) to which the conformance requirement is applicable. Additionally, a cell 
being empty indicates that the conformance requirement is applicable to every release which is covered 
by the present document. 

Examples of the content of cells in this column are given below: 



Sample Content 


Applicability of conformance requirement 




All releases covered by the present document. 


Rel-7 to Rel-8 


Rel-7 to Rel-8 only. 


Rel-9 upwards 


Rel-9 up to the latest release which is covered by the present document. 


Rel-7 


Rel-7 only. 


Rel-7, Rel-9 
upwards 


Rel-7 and for Rel-9 up to the latest release which is covered by the present 
document. 



The absence of this column indicates that all conformance requirements are applicable to every release 
which is covered by the present document. 



IVIandatory 



This mandatory column contains the text of the conformance requirement. 
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4 Test environment 

4.1 Table of optional features 

The device supplier shall state the support of possible options in table 4.1. See clause 3.4 for the format of table 4.1. 

Table 4.1 : Options 



Item 


Option 


Status 


Support 


Mnemonic 


1 


Link management gate supported 







LINK MAN 


2 


WHITELIST contains the H|p of at least one furtlier host 







0_WHITELIST_NON_EMPTY 


3 


Data link layer specified in TS 102 613 [2] is being used 







102 613 


4 


CLT, ISO/IEC 14443-3 [4] Type A 







CLT A 


5 


Card emulation, Type A 







TYPE A 


6 


Card emulation, Type B 







TYPE B 


7 


Card emulation. Type B' 







TYPE B PRIME 


8 


Card emulation. Type F 







TYPE F 
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4.2 Applicability table 



Table 4.2 specifies the applicability of each test case to the device under test. See clause 3.4 for the format of table 4.2. 

Clause 4.5.2 should be referenced for usage of the execution requirements which are referenced in table 4.2 a) and described in table 4.2 c). 

Table 4.2 a): Applicability of tests 



Clause 


Test case number and description 


Release 


Execution 
requirements 


Rel-7 
UICC 


Rel-8 
UICC 


Rel-9 
UICC 


Support 


5.1.2.2 


Test case 1 : processing of RFU host identifier 


Rel-7 




M 


M 


M 




5.1.3.2 


Test case 1 : existence of gates 


Rel-7 




M 


M 


M 




5.1.4.2 


Test case 1 : static pipe deletion - administration gate 


Rel-7 




M 


M 


M 




5.1.4.3 


Test case 2: static pipe deletion - link management gate 


Rel-7 




C101 


C101 


C101 




5.1.4.4 


Test case 3: persistence of pipe state 


Rel-7 




M 


M 


M 




5.1.4.5 


Test case 4: initial pipe state 


Rel-7 




M 


M 


M 




5.1.5.2 


Test case 1 : registry creation 


Rel-7 


SR1 


M 


M 


M 




5.1.5.3 


Test case 2: registry deletion 


Rel-7 


SR2 


M 


M 


M 




5.2.2.2 


Test case 1 : commands/events on pipe which is not open 


Rel-7 




M 


M 


M 




5.3.1.2.1.2 


Test case 1 : ANY SET PARAMETER reception - invalid structure 


Rel-7 




C101 


C101 


C101 




5.3.1.2.1.3 


Test case 2: ANY SET PARAMETER reception - RO registry parameter 


Rel-7 




M 


M 


M 




5.3.1.2.2.2 


Test case 1 : ANY GET PARAMETER reception - invalid structure 


Rel-7 




M 


M 


M 




5.3.1.2.2.3 


Test case 2: ANY GET PARAMETER reception - WO registry parameter 


Rel-7 


SR4 


M 


M 


M 




5.3.1.2.3.2 


Test case 1 : ANY OPEN PIPE reception 


Rel-7 




M 


M 


M 




5.3.1.2.3.3 


Test case 2: ANY OPEN PIPE transmission 


Rel-7 


TR1 


M 


M 


M 




5.3.1.2.4.2 


Test case 1 : ANY CLOSE PIPE reception 


Rel-7 




M 


M 


M 




5.3.1.2.4.3 


Test case 2: ANY CLOSE PIPE transmission 


Rel-7 


TR2 


M 


M 


M 




5.3.2.2 


Test case 1 : response to unknown command 


Rel-7 




M 


M 


M 




5.3.2.3 


Test case 2: responses received out of order, previous command sent by host controller 


Rel-7 




M 


M 


M 




5.3.2.4 


Test case 3: responses received out of order, previous command sent by host 


Rel-7 


TR1 


M 


M 


M 




5.3.3.2 


Test case 1 : reception of unknown events 


Rel-7 




M 


M 


M 




5.4.1.2 


Test case 1 : command and event support for link management gate 


Rel-7 




C101 


C101 


C101 




5.4.1.3 


Test case 2: command and event support for host administration gate 


Rel-7 




M 


M 


M 




5.4.2.1.1.2 


Test case 1 : SESSION IDENTITY 


Rel-7 




M 


M 


M 




5.4.2.1.1.3 


Test case 2: WHITELIST 


Rel-7 


TR3 


M 


M 


M 




5.4.2.2.1.2 


Test case 1 : REC ERROR 


Rel-7 


TR4 


C101 


C101 


C101 




5.4.2.2.2.2 


Test case 1 : REC ERROR 


Rel-7 


ICR1 


C101 


C101 


C101 




5.4.2.3.1.2 


Test case 1 : registry parameters 


Rel-7 




M 


M 


M 




5.5.1.1.2 


Test case 1 : ADM CREATE PIPE 


Rel-7 


TR5 


M 


M 


M 




5.5.1.1.3 


Test case 2: ADM NOTIFY PIPE CREATED from host controller 


Rel-7 




M 


M 


M 




5.5.1.1.4 


Test case 3: ADM NOTIFY PIPE CREATED from other host 


Rel-7 




C102 


C102 


C102 




5.5.1.1.5 


Test case 4: ADM_NOTIFY_PIPE_CREATED with incorrect destination Hi^ 


Rel-7 




M 


M 


M 




5.5.1.1.6 


Test case 5: unsuccessful ADM NOTIFY PIPE CREATED 


Rel-7 


SR5 


M 


M 


M 




5.5.1.2.2 


Test case 1 : sending ADM DELETE PIPE 


Rel-7 


TR6 


M 


M 


M 
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Clause 


Test case number and description 


Release 


Execution 
requirements 


Rel-7 
UICC 


Rel-8 
UICC 


Rel-9 
UICC 


Support 


5.5.1.2.3 


Test case 2: receiving ADM NOTIFY PIPE DELETED 


Rel-7 




M 


M 


M 




5.5.1.3.2 


Test case 1 : ADIVI CLEAR ALL PIPE for data link layer specified in TS 102 613 [2] 


Rel-7 




CI 03 


C103 


CI 03 




5.5.1.3.3 


Test case 2: ADM CLEAR ALL PIPE - static pipes, dynamic pipes to host controller 


Rel-7 




C103 


C103 


CI 03 




5.5.1.3.4 


Test case 3: ADM CLEAR ALL PIPE - dynamic pipes to other host 


Rel-7 




CI 02 


CI 02 


CI 02 




5.5.1.3.5 


Test case 4: ADM CLEAR ALL PIPE - registry parameters 


Rel-7 


1CR1 


C101 


C101 


C101 




5.5.4.2 


Test case 1 : SESSION IDENTITY not changed 


Rel-7 




CI 03 


CI 03 


CI 03 




5.5.4.3 


Test case 2: SESSION IDENTITY changed 


Rel-7 




CI 03 


CI 03 


C103 




5.5.5.2 


Test case 1 : pipe creation from host controller 


Rel-7 




M 


M 


M 




5.5.5.3 


Test case 2: pipe creation from another host 


Rel-7 




CI 02 


C102 


CI 02 




5.5.5.4 


Test case 3: processing of EVT POST DATA 


Rel-7 




M 


M 


M 




5.6.3.3.4.2.2 


Test case 1 : Type A registry values 


Rel-7 


SR8 


C104 


C104 


CI 04 




5.6.3.3.4.3.2 


Test case 1 : Type B registry values 


Rel-7 


SR8 


CI 05 


C105 


CI 05 




5.6.3.3.4.5.2 


Test case 1 : Type F registry values 


Rel-7 


SR8 


C106 


C106 


CI 06 




5.6.4.1.2 


Test case 1 : full power mode 


Rel-7 


SR6 


C107 


C107 


CI 07 




5.6.4.1.3 


Test case 2: full power mode, no EVT CARD ACTIVATED and 
EVT CARD DEACTIVATED 


Rel-7 


SR6 


CI 07 


CI 07 


CI 07 




5.6.4.1.4 


Test case 3: sequence from DEACTIVATED state 


Rel-7 


SR6 


C107 


C107 


CI 07 




5.6.4.1.5 


Test case 4: sequence from DEACTIVATED state, no EVT CARD ACTIVATED or 
EVT CARD DEACTIVATED 


Rel-7 


SR6 


CI 07 


CI 07 


CI 07 




5.6.4.1.6 


Test case 5: low power, power down instead of EVT FIELD OFF 


Rel-7 


SR6 


C107 


C107 


CI 07 




5.6.4.1.7 


Test case 6: EVT FIELD OFF after EVT FIELD ON / SWP interface activation 


Rel-7 


SR6 


CI 07 


CI 07 


CI 07 




5.6.4.1.8 


Test case 7: EVT FIELD OFF after EVT CARD ACTIVATED 


Rel-7 


SR6 


CI 07 


CI 07 


CI 07 




5.6.4.1.9 


Test case 8: EVT FIELD OFF after EVT SEND DATA 


Rel-7 


SR6 


C107 


C107 


CI 07 




5.6.4.1.10 


Test case 9: multiple open card gates 


Rel-7 


SR6 


CI 08 


CI 08 


CI 08 




5.6.4.2.2 


Test case 1 : full power mode 


Rel-7 


SR7 


CI 09 


C109 


CI 09 




5.6.4.2.3 


Test case 2: sequence from DEACTIVATED state 


Rel-7 


SR7 


C109 


C109 


CI 09 




5.6.4.2.4 


Test case 3: low power mode, power down instead EVT FIELD OFF 


Rel-7 


SR7 


C109 


C109 


CI 09 




5.6.4.2.5 


Test case 4: EVT FIELD OFF after EVT FIELD ON / SWP interface activation 


Rel-7 


SR7 


CI 09 


CI 09 


CI 09 




5.6.4.2.6 


Test case 5: EVT FIELD OFF during CLT frames exchange 


Rel-7 


SR7 


C109 


C109 


CI 09 




5.6.4.2.7 


Test case 6: multiple open card gates 


Rel-7 


SR7 


C110 


Clio 


Clio 
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Table 4.2 b): Conditional items referenced by table 4.2 a) 



Conditional item 


Condition 


Description 


C101 


IF 4.1/1 THEN M ELSE N/A 


LINK MAN 


C102 


IF 4.1/2 THEN M ELSE N/A 


WHITELIST NON EMPTY 


CI 03 


IF 4.1/3 THEN M ELSE N/A 


102 613 


C104 


IF 4.1/5 THEN M ELSE N/A 


TYPE A 


C105 


IF 4.1/6 THEN M ELSE N/A 


TYPE B 


C106 


IF 4.1/8 THEN M ELSE N/A 


TYPE F 


C107 


IF 4.1/5 OR 4.1/6 THEN M ELSE N/A 


TYPE AORO TYPE B 


C108 


IF (4.1/5 AND (4.1/6 OR 4.1/7 OR 4.1/8)) OR (4.1/6 
AND (4.1/5 OR 4.1/7 OR 4.1/8)) THEN M ELSE N/A 


(0 TYPE AAND(0 TYPE B OR TYPE B PRIME OR TYPE F)) OR 
(0 TYPE BAND(0 TYPE AORO TYPE B PRIME OR TYPE F)) 


C109 


IF 4.1/4 AND 4.1/5 THEN M ELSE N/A 


CLT AANDO TYPE A 


C110 


IF 4.1/4 AND 4.1/5 AND (4.1/6 OR 4.1/7 OR 4.1/8) 
THEN M ELSE N/A 


CLT AANDO TYPE AAND(0 TYPE B OR TYPE B PRIME OR 
TYPE F) 
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Table 4.2 c): Execution requirements referenced by table 4.2 a) 



Execution 
requirement 


Description 


SR1 


A gate which accepts multiple dynamic pipes and has a RW registry parameter; the default value of the registry parameter shall be 
known. 


SR2 


A gate which has a RW registry parameter; the default value of the registry parameter shall be known. 


SR3 


Void. 


SR4 


A gate which contains at least one WO registry parameter. 


SR5 


A G|Q exists which is reserved for proprietary use or is host specific according to table 2 of TS 102 622 [1], and which is not contained in 
the GATES LIST of the host. 


SR6 


The Dice contains an application which can respond predictably R-APDUs to received G-APDUs. 


SR7 


The Dice contains an application which can respond predictably CLT responses to received CLT commands for non ISO/IEC 14443-4 
[51 Type A. 


SR8 


An application is needed on the UICC, in order for the Host Controller to be able to verify the settings of the registry parameters for the 
given RF technology. 






TR1 


Trigger the host to open PIPE ID MAN. 


TR2 


Trigger the host to close PIPE ID IVIAN. 


TR3 


Trigger the host to write its value of WHITELIST into the registry of the host controller's administration gate. 


TR4 


Trigger the host to write a value of REC_ERROR into the registry of the host controller's link management gate in order to restart an 
error rate measure. 


TR5 


Trigger the host to create a pipe. 


TR6 


Trigger the host to send ADM DELETE PIPE on PIPE^ to delete PIPE LOOP BACK. 






ICR1 


The last value of REC_ERROR in the host's registry for PIPEg is not '0000'. 



NOTE: Clause 4.5.2 should be referenced for the meaning and usage of the execution requirements which are described in table 4.2 c). 
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4.3 Information to be provided by the device supplier 

The device supplier shall provide the information indicated in table 4.3. 

Table 4.3: Default configuration 



Item 


Description 


Presence/Value 


Status 


IVInemonic 


1 


Indication of presence of VERSION_SW, and value if 
supported. 




M 


V_VERSION_SW 


2 


Indication of presence of VERSION_HARD, and 
value if supported. 




M 


V_VERSION_HARD 


3 


Indication of presence of VENDOR_NAME, and value 
if supported. 




M 


V_VENDOR_NAME 


4 


Indication of presence of MODELJD, and value if 
supported. 




M 


V_MODEL_ID 


5 


Indication of presence of HCI_VERSION, and value if 
supported. 




M 


V_HCI_VERSION 


6 


Value of GATES LIST. 




M 


V GATES LIST 


NOTE: Conditional values shall be provided if the corresponding option is supported in the table 4.1 . 



4.4 Test equipment 



The test equipment shall provide a host controller simulator which is connected to the DUT during test procedure 
execution, unless otherwise specified. For test cases which require a further host to be present, the test equipment shall 
further provide a host simulator which is connected to the DUT via the host controller simulator during test procedure 
execution, unless otherwise specified. 

Before execution of each test case, the host network state shall be set back to the state in which it was after the UICC 
was powered up in full power mode using the default SESSION_IDENTITY (in order to instigate a new HCI session 
initialization). 

With respect to the DUT, the host controller simulator shall act as a valid host controller according to TS 102 622 [1] 
unless otherwise specified. In particular, the host controller simulator shall ensure that the values of HOST_LIST and 
GATES_LIST are valid, according to the particular requirements of the test case being executed. 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure that the value GATES_LIST is valid, according to the particular 
requirements of the test case being executed. 

With respect to the DUT, the host network simulation (i.e. host controller simulator and any host simulators) shall 
comprise a valid network according to the specific DUT. The details are out of the scope of the present document. 

4.4.1 Measurement/setting uncertainties 

Void. 

4.4.2 Default conditions for DUT operation 

Unless otherwise specified, the test equipment shall apply the default conditions described in the following clauses 
during test procedure execution. 



4.4.2.1 



General 



The test equipment shall treat the identity check mechanism of the lower layer as having passed (see TS 102 622 [1], 
clause 8.4). 

The test equipment shall use the same SESSION_IDENTITY on power up within an individual test case. 
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4.4.2.2 



Status of Dice interfaces 



If the data link layer in TS 102 613 [2] is used and the DUT is a UICC, the terminal simulator shall not activate the 
TS 102 221 [7] interface or the TS 102 600 [8] interface. 

4.4.3 Minimum/maximum conditions for DUT operation 

Void. 

4.4.4 Conventions 

Unless otherwise specified, ADM_NOTlFY_PlPE_CREATED is sent by the test equipment with source Hjj-, = Hjj-, of 
host controller, destination Hj^ = Hj^ of host and a currently unused Pjj-,. 

If the pipe for a response is not explicitly specified, then the pipe for the response is required to be the pipe on which the 
preceding command was sent. 



4.5 Test execution 
4.5.1 Parameter variations 

Unless otherwise specified, when the data link layer in TS 102 613 [2] is used, all tests shall be carried out once for 
each of following parameter variations in addition to the parameter variations specified individually for each test case. 

Table 4.5.1 : Global parameter variations 



Voltage class and power mode 



C, full power 



C, low power 



Vcc 



Default: in the range of 2,90 V to 3,1 V 



Minimum: in the range of 2.70 V to 2,80 V 



IVlaximum: i 



Default: in 



I Lilt! raiijjfci ui ^,/u V Lu ^,ou v 
in the range of 3,20 V to 3,30 V 



IVIinimum: 



Maximum 



III uia idiiyu ui o,^u . 

the range of 1 ,75 V to 1 ,85 V 
in the range of 1 ,62 V to 1 ,67 V 

■ in thp rannp nf 1 P.^ V tn 1 



Default: in 



Minimum: in the 



in tne range or i ,bz v to i ,b/ v 
: in the range of 1 ,93 V to 1 ,98 V 
the range of 1 ,75 V to 1 ,85 V 



Maximum: i 



inge oi i,/5 v to i,B5 v 
1 the range of 1 ,62 V to 1 ,67 V 
in the range of 1 ,93 V to 1 ,98 V 



The specification of global parameter variations for when other data link layers are used is out of the scope of the 
present document. 

4.5.2 Execution requirements 

Table 4.2, "Applicability of tests", specifies "execution requirements" for several test cases. For these test cases, it has 
not been possible to specify the corresponding test procedure in such a way that it can be guaranteed that the test 
procedure can be executed against every possible DUT. 

Some sample scenarios of test requirements are listed below: 

• The test case requires certain state to be present on the DUT in order to test a particular feature, but there is no 
mandatory requirement in the core specification (TS 102 622 [1]) for this state to be present. 

• The test case requires the DUT to perform a particular operation in order to test that feature, but the core 
specification (TS 102 622 [1]) does not provide a standardized mechanism to trigger that operation to be 
executed by the DUT. 
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The test requirements have been split into various categories, as indicated by table 4.2 c): 

• Static requirements (SRx): information about, for example, particular gates or registry parameters which can 
be used in the test procedure execution. 

• Trigger requirements (TRx): mechanisms for triggering the DUT to perform certain operations. 

• Initial condition requirements (ICRx): information about how to establish initial condition states. 

The DUT supplier should make every effort to provide appropriate information or mechanisms to allow these execution 
requirements to be satisfied for the DUT. 

It is recognized that this might not always be possible. For example, if the configuration of the DUT does not allow for 
the required state to be present; or if it is not possible to provide a particular trigger mechanism for the DUT. In these 
cases, it is acceptable that the test case is not carried out. However, it should be recognized that the consequence is that 
the particular feature will not be tested. 

4.6 Pass criterion 

A test shall only be considered as successful, if the test procedure was carried out successfully under all parameter 
variations with the DUT respecting all conformance requirements referenced in the test procedure. This is subject to the 
additional qualifications described in clause 4.6.1. 

NOTE: Within the test procedures, the RQs are referenced in the step where they are observable. In some cases 
this is different from the step where they occur with respect to the DUT. 

4.6.1 Unanticipated beinaviour from tine DUT 

In the specification of the test procedures, every attempt has been made to ensure that the interface between the 
simulator and the DUT is in a known state before and during test procedure execution. However, as the DUT is an 
autonomous device, it is not possible to fully guarantee this. 

If the DUT unexpectedly closes or deletes a pipe which is intended to be used during a subsequent part of the test 
procedure, this should not be considered as a failure of the DUT, even though the test procedure cannot be completed 
successfully. Instead, the test procedure should be executed again to attempt to execute the test procedure to 
completion. If the unexpected behaviour occurs again, further effort should be applied by the tester to attempt to ensure 
that the unexpected behaviour does not occur. 



5 Test cases 

5.1 HCI arcinitecture 
5.1.1 Overview 

Reference: TS 102 622 [1], clause 4.1. 
There are no conformance requirements for the UICC for the referenced clause. 



5.1.2 Hosts 

5.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.2. 



RQ1 



RQ2 



A host shall not use host identifiers which are RFU. 



A host shall reject received host identifiers which are RFU. 
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NOTE: RQl is a non-occurrence RQ. 



5.1.2.2 



Test case 1 : processing of RFU host identifier 



5.1.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Source Hjq values of: every Hjq value which is RFU as defined in TS 102 622 [1]. 

5.1.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.1.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with the specified source 
H|Q, source G|q = '01' and destination G^q = G|d of loop bacl< gate. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.1.3 Gates 

5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.3. 



RQl 


All hosts shall have one administration gate. 


RQ2 


All hosts shall have one identity management gate. 


RQ3 


All hosts shall have one loop back gate. 


RQ4 


A host shall not use gate identifiers which are RFU. 


RQ5 


Void. 


RQ6 


A host shall not use gate identifiers which are host specific but not yet allocated in TS 1 02 622 [1]. 


RQ7 


Void. 


NOTE: RQ4 and RQ6 are not tested, as they are non-occurrence RQs. 



5.1.3.2 

5.1.3.2.1 
Void. 



Test case 1 : existence of gates 



Test execution 



5.1.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 
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5.1.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source and 
destination G|q = G^q of identity management gate; designate the created 
pipe PIPE ID MAN. 




2 


HUT^HCS 


Send ANY_OK (parameters are not checl<ed). 


RQ1, 
R02 


3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checl<ed). 


R02 


5 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




6 


HUT -^ HCS 


Send ANY_OK. 

Checl< that the GATES_LIST returned contains the G|q of the identity 

management gate and the G^q of the loop back gate. 


RQ2, 
R03 


7 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d = '01' and 
destination G|q = G|q of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


R03 


9 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




10 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


R03 


11 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




12 


HUT ^ HCS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


R03 



5.1.3.3 



Void 



5.1.4 Pipes 



5.1.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.4. 



RQ1 



A host shall not attempt to delete a static pipe. 



RQ2 



A host shall reject any attempts to delete a static pipe. 



RQ3 



The state of a pipe (i.e. open or closed) shall remain persistent if the hosts are powered down and up again. 



RQ4 



The state of a dynamic pipe after creation shall be closed. 



RQ5 



The initial state of a static pipe shall be closed. 



RQ6 



A host shall not use pipe identifiers which are RFU. 



NOTE 1 : R01 and R06 are not tested, as they are non-occurrence ROs. 

NOTE 2: R05 is not tested, as it is not clear when the initial state of the static pipe applies. 



5.1.4.2 

5.1.4.2.1 
Void. 



Test case 1 : static pipe deletion - administration gate 
Test execution 



5.1.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.1.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_DELETED(PIPE^) on PIPE^. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


R02 
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Test case 2: static pipe deletion - link management gate 
Test execution 



5.1.4.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.1.4.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_DELETED(PIPEo) on PIPE^. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.1.4.4 

5.1.4.4.1 
Void. 



Test case 3: persistence of pipe state 
Test execution 



5.1.4.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.1.4.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|q = '01' and 
destination G|p = G|q of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




2 


HUT ^ HCS 


Send ANY OK. 




3 


HCS -> HUT 


Power down host. 




4 


HCS ^ HUT 


Power up host, and proceed until the HCI interface is available. 




5 


HCS -^ HUT 


Send ANY_CLOSE_PIPE on PIPE^. 




6 


HUT ^ HCS 


Send ANY OK. 


RQ3 


7 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ3 


9 


HCS ^ HUT 


SendEVT POST DATA on PIPE LOOP BACK. 




10 


HUT ^ HCS 


Send no message on PIPE LOOP BACK. 


RQ3 


11 


HCS -> HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




12 


HUT ^ HCS 


Send ANY_OK (parameters are not checked). 


RQ3 



5.1 .4.5 Test case 4: initial pipe state 

5.1.4.5.1 Test execution 

Void. 
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5.1.4.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.1.4.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source G|d = '00' and 
destination G|q = G^q of identity management gate; designate the created 
pipe PIPEx. 




2 


HUT^HCS 


Send ANY OK. 




3 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPEx. 




4 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 



5.1.5 Registries 



5.1.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.5. 



For all gates defined in TS 102 622 [1], parameter identifiers in the range of '00' to 'EF' are reserved for 
use in TS 102 622 [1]. 



RQ1 



RQ2 



A new instance of the registry is created for every pipe that connects to the gate. 



RQ3 



Upon pipe creation all registry parameters with access rights Read-write (RW) or Write-only (WO) shall 
be set to their default values. 



Upon pipe creation all read-only (RO) parameters shall be set by the entity managing the registry to an 
appropriate value which may differ from the default values. 



RQ4 



R05 [When a pipe is deleted its registry instance is also deleted. 



NOTE: As the specification of registry parameters is specific to each individual registry, RQ1 , RQ3 and RQ4 

are not tested in this clause, but are tested in other clauses of the present document for each 
individual registry. 



5.1 .5.2 Test case 1 : registry creation 

5.1 .5.2.1 Test execution 

Assignment of terms to entities referenced in SRI: Gjj-, of gate = GATE_X, registry parameter 
identifier = REG_PARAM. 

5.1.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE I is open. 
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5.1.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source G|d = '01' and 
destination G|q = GATE_X; designate the created pipe PIPEa. 




2 


HUT^HCS 


Send ANY OK (parameters are not checl<ed). 




3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPEa. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked) 




5 


HCS ^ HUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEa, with a value 
different from the default value. 




6 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




7 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATE on PIPE^, with source G|d = '01' and 
destination G|q = GATE_X; designate the created pipe PIPEb. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




9 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPEb. 




10 


HUT ^ HCS 


Send ANY OK (parameters are not checked) 




11 


HCS -> HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPEb. 




12 


HUT ^ HCS 


Send ANY OK with parameter value equal to the default value of 
REG PARAM. 


RQ2 


13 


HCS ^ HUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEb, with a value 
different from the default value, and different to the value set in step 5. 




14 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




15 


HCS ^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPEa. 




16 


HUT ^ HCS 


Send ANY OK with parameter value equal to the value set in step 5. 


R02 



5.1 .5.3 Test case 2: registry deletion 

5.1.5.3.1 Test execution 

Assignment of terms to entities referenced in SR2: Gjq of gate = GATE_X, registry parameter 
identifier = REG_PARAM. 

5.1.5.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE[ is open. 



5.1.5.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d = '01' and 
destination G|q = GATE_X; designate the created pipe PIPEa. 




2 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPEa. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




5 


HCS^ HUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEa, with a value 
different from the default value. 




6 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




7 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_DELETED(PIPEa) on PIPE^. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




9 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with G|d = GATE_X; 
designate the created pipe PIPEb. 




10 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




11 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPEb. 




12 


HUT -» HCS 


Send ANY OK (parameters are not checked). 




13 


HCS ^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPEb. 




14 


HUT ^ HCS 


Send ANY OK with parameter value equal to the default value of 
REG PARAM. 


RQ5 
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5.2 



HCP 



5.2.1 HCP packets 

5.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.1. 



RQ1 All hosts shall use the correct structure for transmitted HCP packets. 



RQ2 



All hosts shall recognize correctly structured received HCP packets. 



RQ3 [The destination host forwards the packet to the destination gate. 



NOTE 1 : RQ1 and RQ2 are implicitly tested by the testing of higher layers in other clauses 

of the present document. 
NOTE 2: RQ3 is internal to the host, and is not tested in this clause. It will be implicitly tested 
in many other test cases within the present document. 



5.2.2 HCP message structure 
5.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.2. 



RQ1 




All hosts shall use the correct structure for transmitted HCP messages. 


RQ2 




Type value 3 shall not be used. 


RQ3 




All hosts shall recognize correctly structured received HCP messages. 


RQ4 




A gate shall only accept a command or an event on a pipe when the state of that pipe is open 
unless otherwise stated. 


RQ5 




A gate shall not send a command or event on a pipe when it is waiting for a response to a previous 
command on that pipe unless otherwise stated. 


RQ6 


Rel-9 
upwards 


A gate shall interpret incoming events and commands even while it is waiting for a response to a 
previously sent command. 


NOTE 1 : RQ1 and RQ3 are implicitly tested by the testing of higher layers in other clauses of the present document. 
NOTE 2: R02 and RQ5 are not tested, as they are non-occurrence RQs. 
NOTE 3: Development of test cases for R06 is FFS. 



5.2.2.2 

5.2.2.2.1 
Void. 



Test case 1 : commands/events on pipe which is not open 
Test execution 



5.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEj is open. 
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5.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source and 
destination G|q = G^q of identity management gate; designate the created 
pipe PIPE ID MAN. 




2 


HUT-^HCS 


Send ANY OK (parameters are not checl<ed). 




3 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




4 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 


5 


HCS -> HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




6 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




7 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ4 


9 


HCS^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




10 


HUT -^ HCS 


Send ANY OK (parameters are not checked). 




11 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




12 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 


13 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source 0,0 = 'GO' and 
destination Gi^ = G|q of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




14 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




15 


HCS -» HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




16 


HUT ^ HCS 


Send no message on PIPE LOOP BACK. 


RQ4 


17 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




18 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




19 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




20 


HUT -» HCS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


R04 


21 


HCS^ HUT 


Send ANY CLOSE PIPE on PIPE LOOP BACK. 




22 


HUT -^ HCS 


Send ANY OK (parameters are not checked). 




23 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




24 


HUT ^ HCS 


Send no message on PIPE LOOP BACK. 


RQ4 


25 


HCS -» HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




26 


HUT ^ HCS 


Send ANY_OK (parameters are not checked). 


RQ4 



5.2.3 Message fragmentation 



5.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.3. 



R01 



Message fragmentation shall be used when the size of the message is larger than supported by the 
underlying data link layer. 



R02 



Messages shall be fragmented according to the rules specified in TS 102 622 [1]. 



R03 



The destination gate is responsible for rebuilding the message from the fragmented messages. 



RQ4 



If a reset of the underlying data link layer occurs, fragments of a partially received message shall be 
discarded and a partially sent message shall be re-sent from the beginning. 



NOTE: Development of test cases for RQ1 , RQ2, RQ3 and RQ4 is FFS. 
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5.3 



Instructions 



5.3.1 Commands 



5.3.1.1 



Overview 



5.3.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.1. 



RQ1 



For all gates, hosts shall not use RFU instruction values ('05' to 'OF') in commands. 



RQ2 



For administration gates, hosts shall not use RFU instruction values ('16' to '3F') in commands. 



RQ3 



For gates defined in TS 102 622 [1], hosts shall not use instruction values between '10' and '3F' which 
are not allocated in TS 102 622 [1]. 



NOTE: RQ1 , RQ2 and RQ3 are not tested, as they are non-occurrence RQs. 



5.3.1.2 



Generic commands 



5.3.1.2.1 



ANY SET PARAMETER 



5.3.1 .2.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.1. 



RQ1 



A host shall reject an incorrectly formatted ANY_SET_PARAMETER command. 



RQ2 



A host shall reject an ANY_SET_PARAMETER command if the access right for the parameter does not 
allowed writing (i.e. is not RW or WO). 



RQ3 



A host shall not send an ANY_SET_PARAMETER command if the access right for the parameter does 
not allow writing (i.e. is not RW or WO). 



RQ4 



When a host receives a valid ANY_SET_PARAMETER command, it shall write the parameter value into 
the registry and respond with ANY_OK without any parameters. 



RQS 



Whenever a host sends an ANY_SET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have at least one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 

• The parameter value shall be a valid value as defined for the specific gate. 



NOTE 1 : RQ3 is not tested, as it is a non-occurrence RQ. 

NOTE 2: RQ4 and RQS are not tested in this clause, as they are effectively tested in other clauses of the 

present document for each individual registry parameter. 



5.3.1.2.1.2 

5.3.1.2.1.2.1 
Void. 



Test case 1 : ANY_SET_PARAMETER reception - invalid structure 
Test execution 



5.3.1.2.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEq i^ open. 



5.3.1.2.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_SET_PARAIVIETER with no parameters on PIPEg. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ1 
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5.3.1.2.1.3 

5.3.1.2.1.3.1 
Void. 



Test case 2: ANY_SET_PARAMETER reception - RO registry parameter 
Test execution 



5.3.1.2.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 

5.3.1.2.1.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_SET_PARAMETER(GATES_LIST) on PIPE_ID_MAN, where the 
parameter value is equal to the existing value of GATES_LIST in the host's 
registry. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.3.1.2.2 



ANY GET PARAMETER 



5.3.1.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.2. 



RQ1 



A host shall reject an incorrectly formatted ANY_GET_PARAMETER command. 



RQ2 



A host shall reject an ANY_GET_PARAMETER command if the access right for the parameter does not 
allowed reading (i.e. is not RW or RO). 



RQ3 



A host shall not send an ANY_GET_PARAMETER command if the access right for the parameter does 
not allowed reading (i.e. is not RW or RO). 



RQ4 



When a host receives a valid ANY_GET_PARAMETER command, it shall respond with ANY_OK with 
the value of the parameter. 



RQ5 



Whenever a host sends an ANY_GET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have exactly one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 



NOTE 1 : RQ3 is not tested, as it is a non-occurrence RO. 

NOTE 2: R04 and RQ5 are not tested, as they are effectively tested in other clauses of the present document 

for each individual registry parameter. 



5.3.1.2.2.2 

5.3.1.2.2.2.1 
Void. 



Test case 1 : ANY_GET_PARAMETER reception - invalid structure 
Test execution 



5.3.1.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (P1PE_ID_MAN) has been created to the host's identity management gate, and is open. 
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5.3.1.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY GET PARAMETER with no parameters on PIPE ID MAN. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


3 


HCS ^ HUT 


Send ANY_GET_PARAMETER containing parameters of length 2, with each 
byte containing the value of the GATES LIST identifier, on PIPE ID MAN. 




4 


HUT^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 



5.3.1.2.2.3 



5.3.1.2.2.3.1 



Test case 2: ANY_GET_PARAMETER reception - WO registry parameter 
Test execution 



Assignment of terms to entities referenced in SR4: Gjq of gate = GATE_X, registry parameter 
identifier = REG_PARAM. 

5.3.1.2.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_X) has been created to the gate with Gj^, = GATE_X, and is open. 



5.3.1.2.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE X. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.3.1.2.3 



ANY OPEN PIPE 



5.3.1.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.3. 



RQ1 A host shall reject an incorrectly formatted ANY_OPEN_PIPE command. 



RQ2 



When a host other than the host controller receives a valid ANY_OPEN_PIPE command on a closed 
pipe, it shall open the pipe and return ANY_OK with a parameter containing the "number of pipes already 
open on this gate before the execution of the command" 



RQ3 



When a host sends an ANY_OPEN_PIPE command, it shall contain no command parameters. 



RQ4 [When a host receives ANY_OK in response to an ANY_OPEN_PIPE command, it shall open the pipe. 
NOTE: In TS 102 622 [1], it is not clear whether ANY_OPEN_PIPE is valid over a pipe which is already open. 
This is therefore not listed as a conformance requirement. 



5.3.1.2.3.2 

5.3.1.2.3.2.1 
Void. 



Test case 1 : ANY_OPEN_PIPE reception 
Test execution 



5.3.1 .2.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_CLOSE_PIPE on PIPE^. 




2 


HUT^HCS 


Send ANY OK. 




3 


HCS ^ HUT 


Send ANY_OPEN_PIPE with parameter 'GO' on PIPE^. 




4 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


5 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and destination 
G|Q = G|p of identity management gate. 




6 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


7 


HCS ^ HUT 


Send ANY_OPEN_PIPE on PIPE^. 




8 


HUT ^ HCS 


Send ANY OK with parameter 'GG'. 


RQ2 


9 


HCS ^ HUT 


Send ADIVI_NOTIFY_PIPE_CREATED on PIPE^, with source and destination 
G|p = G|p of identity management gate; designate the created pipe 
PIPE ID MAN. 




10 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


11 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




12 


HUT ^ HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command (see note). 


RQ2 


13 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




14 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


15 


HCS -^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




16 


HUT ^ HCS 


Send ANY OK. 




17 


HCS -^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




18 


HUT ^ HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command (see note). 


RQ2 


19 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d = 'G1' and 
destination G|p = 0,0 of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




20 


HUT ^ HCS 


Send ANY OK. 




21 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




22 


HUT ^ HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command (see note). 


RQ2 


NOTE: The test equipment shall calculate the number of pipes already open on the gate before the execution 
of the command, taking into account any pipes which have been opened by the host. 
Example for step 12: if no pipes were opened to the host controller's identity management gate before 
the execution of the test procedure and no further pipes have been opened by the host, this value 
would be 'GO'. 



5.3.1.2.3.3 

5.3.1.2.3.3.1 
Void. 



Test case 2: ANY OPEN PIPE transmission 



Test execution 



5.3.1.2.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 
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5.3.1.2.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




2 


HUT^HCS 


Send ANY OK. 




3 


User ^ HUT 


Trigger the host to open PIPE ID MAN. 




4 


HUT ^ HCS 


Send ANY OPEN PIPE on PIPE ID MAN. 


RQ3 


5 


HCS ^ HUT 


Send ANY OK. 




6 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




7 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ4 



5.3.1.2.4 



ANY CLOSE PIPE 



5.3.1.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.4. 



R01 



A host shall reject an incorrectly formatted ANY_CLOSE_PIPE command. 



R02 



When a host receives a valid ANYCLOSEPIPE on an open pipe, it shall close the pipe and respond 
with ANYOK and no parameters. 



R03 



When a host sends an ANY_CLOSE_PIPE command, it shall contain no command parameters. 

When a host receives ANY_OK in response to an ANY_CLOSE_PIPE command, it shall close the pipe. 



R04 



5.3.1.2.4.2 

5.3.1.2.4.2.1 
Void. 



Test case 1 : ANY_CLOSE_PIPE reception 
Test execution 



5.3.1 .2.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEj is open. 



5.3.1.2.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_CLOSE_PIPE with parameter '00' on PIPE^. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


3 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and 
destination G|q = G|q of identity management gate; designate the created 
pipe PIPE ID MAN. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ1 


5 


HCS ^ HUT 


Send ANY_CLOSE_PIPE on PIPE^. 




6 


HUT ^ HCS 


Send ANY OK with no parameters. 


RQ2 


7 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and 
destination G|q = G|d of identity management gate. 




8 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ2 


9 


HCS^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




10 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




11 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




12 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




13 


HCS ^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




14 


HUT ^ HCS 


Send ANY OK with no parameters. 


RQ2 


15 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




16 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ2 
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Test execution 



5.3.1.2.4.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 

5.3.1 .2.4.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -> HUT 


Trigger the host to close PIPE ID MAN. 




2 


HUT^HCS 


Send ANY CLOSE PIPE on PIPE ID MAN. 


R03 


3 


HCS ^ HUT 


Send ANY OK. 




4 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




5 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 



5.3.1.3 Administration commands 

5.3.1.3.1 ADM_CREATE_PIPE 

5.3.1 .3.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.1. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.1 of the present 
document. 



5.3.1.3.2 



ADM NOTIFY PIPE CREATED 



5.3.1.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.2. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.1 of the present 
document. 



5.3.1.3.3 



ADM DELETE PIPE 



5.3.1.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.3. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.2 of the present 
document. 



5.3.1.3.4 



ADM NOTIFY PIPE DELETED 



5.3.1.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.4. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.2 of the present 
document. 
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5.3.1.3.5 



ADM CLEAR ALL PIPE 



5.3.1.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.5. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.3 of the present 
document. 



5.3.1.3.6 



ADM NOTIFY ALL PIPE CLEARED 



5.3.1.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.6. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.3 of the present 
document. 



5.3.2 Responses 



5.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.2. 



RQ1 A response shall be sent to all commands received even to those unknown to the receiving gate. 



RQ2 



Responses received out of order (i.e. if no command was sent previously) shall be discarded. 



RQ3 



For a received command which is defined in table 16 in TS 102 622 [1], hosts shall only return a 
response code which is specified for that command in table 1 6 in TS 1 02 622 [1 ]. 



NOTE: Development of test cases for RQ3 is FFS. 



5.3.2.2 

5.3.2.2.1 
Void. 



Test case 1 : response to unknown command 
Test execution 



5.3.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 

5.3.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send command with an RFU instruction value on PIPE^. 




2 


HUT^HCS 


Send response (contents are not checked). 


RQ1 


3 


HCS ^ HUT 


Send command with an RFU instruction value on PIPE ID MAN. 




4 


HUT ^ HCS 


Send response (contents are not checked). 


RQ1 



£75/ 



Release 9 
5.3.2.3 

5.3.2.3.1 
Void. 



36 



ETSI TS 102 695-2 V9.1.0 (2013-04) 



Test case 2: responses received out of order, previous command sent by 
host controller 

Test execution 



5.3.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.3.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




2 


HUT^HCS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 




3 


HCS -> HUT 


Send response with ANY OK and no parameters on PIPE ID MAN. 




4 


HUT 


No message on PIPE ID MAN. 


R02 


5 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




6 


HUT ^ HCS 


Send response with ANY OK and same value of GATES LIST as in step 2. 


RQ2 



5.3.2.4 Test case 3: responses received out of order, previous command sent by 

host 



5.3.2.4.1 
Void. 



Test execution 



5.3.2.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.3.2.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




2 


HUT ^ HCS 


Send ANY OK. 




3 


User ^ HUT 


Trigger the host to open PIPE ID MAN. 




4 


HUT -» HCS 


Send ANY OPEN PIPE on PIPE ID MAN. 




5 


HCS -» HUT 


Send ANY OK on PIPE ID MAN. 




6 


HCS ^ HUT 


Send ANY E NOKonPIPE ID MAN. 




7 


HUT 


No message on PIPE ID MAN. 


R02 


8 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




9 


HUT ^ HCS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 


RQ2 
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5.3.3 Events 



5.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.3. 



RQ1 Unknown events received shall be discarded. 



RQ2 



When the host sends EVT_HCI_END_OF_OPERATION, it shall contain no parameters. 



RQ3 



For gates defined in TS 102 622 [1], hosts shall not use event values which are not allocated in 
TS102 622[1]. 



NOTE 1 : No RQs are specified for when the host should send EVT_HCI_END_OF_OPERATION, as the 

conditions for sending this event are internal to the host. 
NOTE 2: Development of test cases for RQ2 is FFS. 
NOTE 3: RQS is not tested, as it is a non-occurrence RQ. 



5.3.3.2 

5.3.3.2.1 
Void. 



Test case 1 : reception of unknown events 
Test execution 



5.3.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.3.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




2 


HUT^HCS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 




3 


HCS ^ HUT 


Send event with an RFU instruction value on PIPE ID MAN. 




4 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




5 


HUT ^ HCS 


Send response with ANY OK and same value of GATES LIST as in step 2. 


R01 



5.4 



GATES and subclauses 



5.4.1 GATES 



5.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7. 



R01 I Gates shall support the commands and events specified for them in tables 1 8 and 1 9 of TS 1 02 622 [1 ] 



NOTE 
NOTE 
NOTE 



NOTE 
NOTE 



1 : In this clause, RQ1 is only tested for the management gates. Other clauses may test RQ1 for other 

gates as applicable. 
2: ANY_GET_PARAMETER and ANY_SET_PARAMETER are not tested in this clause, as they are 

tested in the specific clauses for each gate for testing registry parameters. 
3: ADM_NOTIFY_PIPE_CREATED, ADM_NOTIFY_PIPE_DELETED and 

ADM_NOTIFY_ALL_PIPE_CLEARED are not tested for the host administration gate, as they are 

tested in the specific clauses for each command. 
4: EVT_POST_DATA is not tested for the loop back gate, as it is tested in the clause 5.5.5. 
5: EVT_HOT_PLUG is not tested for the host administration gate, as the reaction of the host is not 

specified in TS 102 622 [1]. 
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Test case 1 : command and event support for link management gate 
Test execution 



5.4.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE,, is open. 



5.4.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_CLOSE_PIPE on PIPEg. 




2 


HUT^HCS 


Send ANY OK (parameters are not checked). 


RQ1 


3 


HCS ^ HUT 


Send ANY_OPEN_PIPE on PIPEg. 




4 


HUT ^ HCS 


Send ANY_OK (parameters are not checked). 


RQ1 



5.4.1 .3 Test case 2: command and event support for management gates except link 

management gate 



5.4.1.3.1 



Test execution 



The test procedure shall be executed once for each of following parameters, indicating the pipe to be used in the test 
procedure: 

• PIPEj; 

• a pipe which has been created from the host controller's identity management gate to the host's identity 
management; 

• a pipe which has been created from gate with Gjp = '01' on the host controller to the host's loop back gate. 

5.4.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• The pipe indicated in the test execution clause is open. 

5.4.1 .3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY CLOSE PIPE on the pipe indicated in the test execution clause. 




2 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ1 


3 


HCS ^ HUT 


Send ANY OPEN PIPE on the pipe indicated in the test execution clause. 




4 


HUT ^ HCS 


Send ANY_OK (parameters are not checked). 


RQ1 
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5.4.2 Management gates 
5.4.2.1 Administration gates 

5.4.2.1 .1 Host controller administration gate 



5.4.2.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.1.1. 



RQ1 



The host shall only set values of SESSIONJDENTITY with length 8 bytes. 



RQ2 



The session identity shall be modified by the host whenever a modification of the configuration is 
performed by the host. 



RQ3 



The default value of the session identity shall never be written by a host. 



RQ4 



The session identity shall use random values. 



RQ5 



The host shall adhere to the access condition of RO for MAX PIPE. 



RQ6 



The host shall only set values of WHITELIST containing valid host identifiers (including proprietary host 
identifiers but excluding RFU host identifiers) as specified in table 1 in TS 102 622 [1], and not containing 
the host controller's host identifier and the host's own host identifier; an empty array is allowed. 



RQ7 



The host shall adhere to the access condition of RO for HOST LIST. 



NOTE 1 : RQ2 is not tested in this clause. It is tested in the context of HCI session initialization in clause 5.5.4. 

As other circumstances in which the host may modify the configuration are not evident, it is not tested 

further in this clause. 
NOTE 2: RQ5 and RQ7 are not tested, as they are non-occurrence RQs. 



5.4.2.1.1.2 



Test case 1 : SESSION IDENTITY 



5.4.2.1.1.2.1 Test execution 

Run this test procedure in full power mode only. 

5.4.2.1.1.2.2 Initial conditions 
• The host is not powered up. 

5.4.2.1.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^ ^ HCS 


Perform HCI session initialization. 




3 


HUT^ HCS 


Send ANY_SET_PARAMETER(SESSION_IDENTITY) on PIPE^. 
Check value is 8 bytes long, and is different from the default value. 


RQ1, 
R03 


4 


HCS ^ HUT 


Send ANY OK. 




5 




Execute steps 7 to 10 ten times. 




6 


HCS ^ HUT 


Power down host. 




7 


HCS -^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




8 


HUT^ ^ HCS 


Perform HCI session initialization. 




9 


HUT ^ HCS 


Send ANY_SET_PARAMETER(SESSION_IDENTITY) on PIPE^. 

Check value is 8 bytes long, is different from the default value, and is 
different from any value previously sent by the host in the test procedure. 


RQ1, 
RQS, 
R04 


10 


HCS ^ HUT 


Send ANY OK. 





5.4.2.1.1.3 



Test case 2: WHITELIST 



5.4.2.1.1.3.1 
Void. 



Test execution 
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5.4.2.1.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.4.2.1.1.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -^ HUT 


Trigger the host to write its value of WHITELIST into the registry of the host 
controller's administration gate. 




2 


HUT^HCS 


Send ANY_SET_PARAMETER(WHITELIST) on PIPE^. 


RQ6 


3 


HCS ^ HUT 


Send ANY OK. 





5.4.2.1.2 



Host administration gate 



5.4.2.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.1.2 and 4.5. 



RQ1 



4.5 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 1 02 622 [1 ] 
shall not be present in the registry. 



NOTE: Development of test cases for RQ1 is FFS. 



5.4.2.2 Link management gate 

5.4.2.2.1 Host controller link management gate 

5.4.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.2.1. 



I R01 |The host shall only set values of REC_ERROR with length 2 bytes. 



5.4.2.2.1 .2 Test case 1 : REC_ERROR 

5.4.2.2.1.2.1 Test execution 
Void. 

5.4.2.2.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEq is open. 



5.4.2.2.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HUT 


Trigger the host to write a value of REC_ERROR into the registry of the host 
controller's link management gate in order to restart an error rate measure. 




2 


HUT ^ HCS 


Send ANY_SET_PARAMETER(REC_ERROR) on PiPEg. 


RQ1 


3 


HCS -» HUT 


Send ANY OK. 
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Host link management gate 



5.4.2.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.2.1 and 4.5. 



RQ1 


4.5 


Registry parameters whicli are in tlie range of '00' to 'EF' but whicli are not allocated in TS 1 02 622 [1 ] 
shall not be present in the registry. 


RQ2 


7.1.2.1 


The host shall use a default value for REG ERROR of '0000'. 


RQ3 


7.1.2.1 


The host shall apply the access condition of RW to REG ERROR. 


RQ4 


7.1.2.1 


The host shall only accept values of REG ERROR of length 2 bytes. 


NOTE: Development of test cases for RQ1 is FFS. 



5.4.2.2.2.2 



Test case 1 : REC ERROR 



5.4.2.2.2.2.1 Test execution 

Run this test procedure in full power mode only. 

5.4.2.2.2.2.2 Initial conditions 

• The last value of REC_ERROR in the host's registry for PIPE^ is not '0000'. 

• The interface is powered down. 



5.4.2.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HGS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^ ^ 
HGS 


Perform HGI session initialization, up to and including setting new value of 
SESSION IDENTITY. 




3 


HGS 


Wait until the HGI interface is idle; i.e. no further communication is expected. 




4 


HGS ^ HUT 


Send ANY_OPEN_PIPE on PIPEg. 




5 


HUT ^ HGS 


Send response (contents are not checked) 




6 


HGS ^ HUT 


Send ANY_GET_PARAMETER(REG_ERROR) on PIPEg. 




7 


HUT ^ HGS 


Send ANY_OK with parameter value '0000' (see note). 


RQ2, 
R03 


8 


HGS ^ HUT 


Send ANY_SET_PARAMETER(REG_ERROR, '0000') on PIPEg. 




9 


HUT ^ HGS 


Send ANY OK. 


R03 


10 


HGS ^ HUT 


Send ANY_SET_PARAMETER(REG_ERROR, '000000') on PIPEg. 




11 


HUT ^ HGS 


Send response containing an allowed error response code for the command. 


R04 


NOTE: This assumes that the HGI session initialization procedure has not resulted in any errors at the data 
link layer which would result in the incrementing of REG ERROR. 
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5.4.2.3 Identity management gate 

5.4.2.3.1 Local registry 



5.4.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.3 and 4.5. 

NOTE: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
local registry. The requirements for the remote registry are contained in clause 5.4.2.3.2. 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



RQ1 



4.5 



RQ2 



7.1.3 



The registry of the identity management gate shall be persistent. 



RQ3 



7.1.3 



This gate shall be provided by all hosts and the host controller. 



RQ4 



7.1.3 



f present in the host, the host shall use a value for VERSION_SW of length 3 bytes. 



RQ5 



7.1.3 



f present in the host, the host shall apply the access condition of RO to VERSION_SW. 



RQ6 



7.1.3 



f present in the host, the host shall use a value for VERSION_HARD of length 3 bytes. 



RQ7 



7.1.3 



f present in the host, the host shall apply the access condition of RO to VERSION_HARD. 



RQ8 



7.1.3 



f present in the host, the host shall use a value for VENDOR_NAME of maximum length 20 bytes with 
UTF8 coding. 



RQ9 



7.1.3 



f present in the host, the host shall apply the access condition of RO to VENDOR_NAME. 



RQ10 



7.1.3 



f present in the host, the host shall use a value for MODEL_ID of length 1 byte. 



RQ11 



7.1.3 



f present in the host, the host shall apply the access condition of RO to MODELJD. 



RQ12 



7.1.3 



f present in the host, the host shall apply the access condition of RO to HCI_VERSION. 



RQ13 



7.1.3 



The host shall use a value for GATES_LIST containing the list of all gates that accept dynamic pipes as 
an array of gate identifiers. 



RQ14 



7.1.3 



The host shall apply the access condition of RO to GATES_LIST. 



RQ15 



7.1.3 



A host according to the present document shall set the HCI_VERSION parameter if provided to '01 ' 



NOTE 1 : Development of test cases for R01 is FFS. 

NOTE 2: R02 is not tested within this clause, as the registry contains no writeable parameters which can be used to 

test the persistence of the registry. 
NOTE 3: R03 is also covered in clause 4.3 of TS 102 622 [1], covered by clause 5.1.3 of the present document. This 
RO is therefore not tested within this clause, as it is effectively tested in clause 5.1.3. 



5.4.2.3.1.2 



Test case 1 : registry parameters 



5.4.2.3.1.2.1 



Test execution 



The test procedure shall be executed for each of the parameters in the following table: 



Registry parameter 

(designated 
REG PARAM) 


Presence 


Expected value 

(designated VALUE) 


Value to be used in 
ANY SET PARAMETER 

(designated VALUE SET) 


RQ to be 

checked in 

steps 2 and 6 


RQ to be 

checked in 

step 4 


VERSION SW 





V VERSION SW 


'01 01 or 


R04 


R05 


VERSION HARD 





V VERSION HARD 


'01 01 01' 


R06 


R07 


VENDOR NAME 





V VENDOR NAME 


'56 65 6E 64 6F 72' 


R08 


R09 


MODEL ID 





V MODEL ID 


'01' 


RO10 


R011 


HO! VERSION 





V HCI VERSION 


'01' 


RQ15 


R012 


GATES LIST 


M 


V GATES LIST 


'04 05' 


R013 


RQ14 



5.4.2.3.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 
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5.4.2.3.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE ID MAN. 




2 


HUT-> HCS 


If REG_PARAM is supported by the device under test as indicated in 

table 4.3, send ANY_OK with parameter value equal to VALUE. 

If REG_PARAM is not supported by the device under test as indicated in 

table 4.3, send response containing an allowed error response code for the 

command. 


See test 

execution 

clause 


3 


HCS ^ HUT 


Send ANY SET PARAMETER(REG PARAM, VALUE SET) on 
PIPE ID MAN. 




4 


HUT ^ HCS 


Send response containing an allowed error response code for the 
command. 


See test 

execution 

clause 


5 


HCS ^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE ID MAN. 




6 


HUT ^ HCS 


If REG_PARAM is supported by the device under test as indicated in 

table 4.3, send ANY_OK with parameter value equal to VALUE. 

If REG_PARAM is not supported by the device under test as indicated in 

table 4.3, send response containing an allowed error response code for the 

command. 


See test 

execution 

clause 



5.4.2.3.2 



Remote registry 



5.4.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.3. 

NOTE: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
remote registry. The requirements for the local registry are contained in clause 5.4.2.3.1. 



RQ1 



The host shall adhere to the access condition of RO for VERSION SW in the host controller. 



RQ2 



The host shall adhere to the access condition of RO for VERSION HARD in the host controller. 



RQ3 



The host shall adhere to the access condition of RO for VENDOR NAME in the host controller. 



RQ4 



The host shall adhere to the access condition of RO for MODEL ID in the host controller. 



RQ5 



The host shall adhere to the access condition of RO for HCI VERSION in the host controller. 



RQ6 



The host shall adhere to the access condition of RO for GATES LIST in the host controller. 



RQ7 



Every host shall manage backward compatibility with previous HCI versions and use only commands and 
parameters defined in the specification having the lower HCI version number between of the 2 hosts 
involved in a transaction. 



RQ8 



A host connected to a host with higher HCI version number shall operate according to its own version. 
1 : R01 , R02, R03, R04, R05 and RQ6 are not tested, as they are non-occurrence ROs. 
2: In the current version of the present document, there are no previous HCI versions. R07 is therefore 
not tested in the current version of the present document. 
NOTE 3: Development of test cases for ROS is FFS. 



NOTE 
NOTE 



5.4.2.4 



Loop back gate 



5.4.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.4 and 4.5. 



R01 



4.5 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in 
TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for RQ1 is FFS. 



5.4.3 Generic gates 

Reference: TS 102 622 [1], clause 7.2. 
There are no conformance requirements for the UlCC for the referenced clause. 
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RQ1 


6.1.3.1 


When a host sends an ADM_CREATE_PIPE command, the command parameters shall be 3 bytes long, 
and contain valid G|qS and H|p. 


RQ2 


6.1.3.2 


When a host receives an ADM_NOTIFY_PIPE_CREATED command, it shall respond with ANY_OK with 
no parameters if it accepts the pipe. 


RQ3 


6.1.3.2 


If a host receives an ADMNOTIFYPIPECREATED command containing a destination H|p which is 
not the H|p of the host, it shall reject the pipe creation. 


RQ4 


8.1.1 


If host B does not accept the creation of the pipe, it shall respond to ADM_NOTIFY_PIPE_CREATED 
with an appropriate response code. 


RQ5 


6.1.3.1 


When receiving ADM_NOTIFY_PIPE_CREATED, the host shall accept any gate Identifier being used as 
source gate. 


NOTE: Development of test cases for RQ5 is FFS. 



5.5.1.1.2 

5.5.1.1.2.1 
Void. 



Test case 1 : ADM CREATE PIPE 



Test execution 



5.5.1.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.1.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HUT 


Trigger the host to create a pipe. 




2 


HUT^ HCS 


Send ADM_CREATE_PIPE on PIPE^; designate the created pipe PIPE_ID_IVIAN. 


RQ1 


3 


HCS ^ HUT 


Send ANY OK with valid response parameters. 




4 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




5 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ1 



5.5.1.1.3 

5.5.1.1.3.1 
Void. 



Test case 2: ADM NOTIFY PIPE CREATED from host controller 



Test execution 
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5.5.1.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.1.1.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|o '01' and 
destination G|q of the loop back gate; designate the create pipe 
PIPE LOOP BACK. 




2 


HUT^HCS 


Send ANY OK with no parameters. 


RQ2 


3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


5 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




6 


HUT ^ HCS 


Send EVT_POST_DATA containing '01 02 03 04' on PIPE_LOOP_BACK. 


R02 



5.5.1.1.4 

5.5.1.1.4.1 
Void. 



Test case 3: ADM NOTIFY PIPE CREATED from other host 



Test execution 



5.5.1.1.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE[ is open. 



5.5.1.1.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^ with source H^^ equal to a 
value in the WHITELIST of the host, source G|q = '01 ' and destination G|p = 
G|Q of the loop back gate; designate the created pipe PIPE_LOOP_BACK. 




2 


HUT ^ HCS 


Send ANY OK with no parameters. 


RQ2 


3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


5 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




6 


HUT ^ HCS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


R02 



5.5.1.1.5 

5.5.1.1.5.1 
Void. 



Test case 4: ADM_NOTIFY_PIPE_CREATED with incorrect destination Hid 
Test execution 



5.5.1.1.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^ with destination H^^ equal 
to a proprietary H^ according to table 1 of TS 102 622 [1] but which is not 
equal to the H|o of the host, with source G|q = '01 ' and destination G|q = G|d 
of the loop back gate. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ3 



5.5.1.1.6 



Test case 5: unsuccessful ADM NOTIFY PIPE CREATED 



5.5.1.1.6.1 Test execution 

Assignment of terms to entities referenced in SR5: Gjq of gate = GATE_UNSUPPORTED. 

5.5.1.1.6.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.1.1.6.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d = '01' and 
destination G^ equal to GATE_UNSUPPORTED. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 



5.5.1.2 



Pipe deletion 



5.5.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.2,6.1.3.3 and 6.1.3.4. 



RQ1 


6.1.3.3 


When a host sends an ADIVI DELETE PIPE command, the command parameters shall be 1 byte long. 


RQ2 


6.1.3.3 


When a host sends an ADIVI_DELETE_PIPE command, the host that requested the deletion of the pipe 
shall be the source host or destination host. 


RQ3 


6.1.3.4 


When a host receives a valid ADM_NOTIFY_PIPE_DELETED command, it shall respond with ANY_OK 
with no parameters. 


NOTE: RQ2 is not tested, as it is a non-occurrence RQ. 



5.5.1.2.2 

5.5.1.2.2.1 
Void. 



Test case 1 : sending ADi\/l_DELETE_PIPE 
Test execution 



5.5.1.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -» HUT 


Trigger the host to send ADM_DELETE_PIPE on PIPE^ to delete 
PIPE LOOP BACK. 




2 


HUT^HCS 


Send ADM_DELETE_PIPE on PIPE^, with parameter value of length 1 and 
equal to PIPE LOOP BACK. 


RQ1 


3 


HCS ^ HUT 


Send ANY OK. 




4 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




5 


HUT ^ HCS 


No messages on PIPE LOOP BACK. 


RQ1 


6 


HCS -» HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




7 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


RQ1 



5.5.1.2.3 

5.5.1.2.3.1 
Void. 



Test case 2: receiving ADM_NOTIFY_PIPE_DELETED 
Test execution 



5.5.1 .2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 

5.5.1 .2.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADIV1_ NOTIFY_PIPE_DELETED on PIPE^, with parameter value of 
length 1 and equal to PIPE LOOP BACK. 




2 


HUT ^ HCS 


Send ANY OK. 


RQ3 


3 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




4 


HUT ^ HCS 


No messages on PIPE LOOP BACK. 


RQ3 


5 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




6 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


RQ3 



5.5.1.3 



Clear all Pipes 



5.5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.3, 6.1.3.5 and 6.1.3.6. 



RQ1 


6.1.3.5 


When the host sends an ADIVI_CLEAR_ALL_PIPE command and the data link layer specified in 
TS 102 613 [2] is used, the command parameters shall be two bytes long. 


RQ2 


6.1.3.5 


When the data link layer specified in TS 102 613 [2] is used, the identity reference data in the 
ADIVI CLEAR ALL PIPE command shall contain random elements. 


RQ3 


6.1.3.5 


When the host receives ANY_OK in response to an ADIVI_CLEAR_ALL_PIPE command, it shall 
consider that all dynamic pipes connected to it are deleted, all static pipes connected to it are closed, 
and all registry values related to static pipes connected to it are set to their default values. 


RQ4 


6.1.3.6 


When the host receives a valid ADIVI_NOTIFY_ALL_PIPE_CLEARED command, and the requesting 
host is not the host controller, the host shall consider all dynamic pipes between the host and the 
requesting host to be deleted. 
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RQ5 



6.1.3.6 



When the host receives a valid ADI\/l_NOTIFY_ALL_PIPE_CLEARED command, and the requesting 
host is the host controller, the host shall consider all dynamic pipes between the host controller and the 
host to be deleted, and all static pipes between the host and the host controller to be closed. 



RQ6 



6.1.3.6 



The host shall respond to an ADIVI_NOTIFY_ALL_PIPE_CLEARED command with an ANY_OK without 
parameters. 



NOTE: Development of test cases for RQ4, RQ5 and RQ6 is FFS. 



5.5.1 .3.2 Test case 1 : ADM_CLEAR_ALL_PIPE for data link layer specified in TS 1 02 61 3 

5.5.1.3.2.1 Test execution 

Run this test procedure in full power mode only. 

5.5.1.3.2.2 Initial conditions 
• The host is not powered up. 

5.5.1 .3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^HCS 


Send ADIVI_CLEAR_ALL_PIPE on PIPE^, with a parameter value of length 
2 bytes (see note). 


RQ1 


3 


HCS -^ HUT 


Send ANY OK. 




4 


HCS 


Wait for HCI session initialization to be completed, and for the HCI interface to 
be idle; i.e. no further communication is expected. 




5 




Execute steps 6 to 9 ten times. 




6 


HCS ^ HUT 


Power down host. 




7 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




8 


HUT -» HCS 


Send ADM_CLEAR_ALL_PIPE on PIPE^, with a parameter value of length 

2 bytes, and with a value different from any value previously sent by the host 
in the test procedure (see note). 


RQ2 


9 


HCS ^ HUT 


Send ANY OK. 




NOTE: Other commands may be sent prior to the ADM_CLEAR_ALL_PIPE command. 



5.5.1 .3.3 Test case 2: ADM_CLEAR_ALL_PIPE - static pipes, dynamic pipes to host 

controller 

5.5.1.3.3.1 Test execution 

Run this test procedure in full power mode only. 

5.5.1 .3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 
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5.5.1.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power down host. 




2 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




3 


HUT ^ HCS 


Send ADIVI_CLEAR_ALL_PIPE on PIPE^; parameter value is not checked 
(see note 1). 




4 


HCS ^ HUT 


Send ANY OK. 




5 


HUT ^ HCS 


Send ANY_OPEN_PIPE on PIPE^. 


RQ3 


6 


HCS ^ HUT 


Send ANY OK. 




7 


HCS 


See note 2. 




8 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




9 


HUT ^ HCS 


No messages on PIPE LOOP BACK. 


RQ3 


10 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




11 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


RQ3 


NOTE 1 : Other commands may be sent prior to the ADM_CLEAR_ALL_PIPE command. 

NOTE 2: The host controller simulator shall not use PIPE LOOP BACK for any subsequent pipe creation. 



5.5.1 .3.4 Test case 3: ADM_CLEAR_ALL_PIPE - dynamic pipes to other host 

5.5.1.3.4.1 Test execution 

Run this test procedure in full power mode only. 

5.5.1.3.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_LOOP_BACK) has been created from gate '01' on a host whose Hjq is in the WHITELIST of 
the host to the host's loop back gate, and is open. 



5.5.1.3.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power down host. 




2 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




3 


HUT ^ HCS 


Send ADIVI_CLEAR_ALL_PIPE on PIPE^; parameter value is not checked 
(see note 1). 




4 


HCS -^ HUT 


Send ANY OK. 




5 


HCS 


See note 2. 




6 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




7 


HUT -^ HCS 


No messages on PIPE LOOP BACK. 


R03 


8 


HCS -^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




9 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


R03 


NOTE 1 : Other commands may be sent prior to the ADM_CLEAR_ALL_PIPE command. 

NOTE 2: The host controller simulator shall not use PIPE_LOOP_BACK for any subsequent pipe creation. 



5.5.1.3.5 



Test case 4: ADM_CLEAR_ALL_PIPE - registry parameters 



5.5.1.3.5.1 Test execution 

Run this test procedure in full power mode only. 
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5.5.1 .3.5.2 Initial conditions 

• REC_ERROR in the registry of the host for PIPEq has a value which is different from the default value. 

• The host is not powered up. 



5.5.1.3.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^HCS 


Send ADIVI_CLEAR_ALL_PIPE on PIPE^; parameter value is not checked 
(see note 1). 




3 


HCS -^ HUT 


Send ANY OK. 




4 


HCS -^ HUT 


Send ANY_OPEN_PIPE on PIPEg. 




5 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




6 


HCS ^ HUT 


Send ANY_GET_PARAMETER(REC_ERROR) on PiPEg. 




7 


HUT -^ HCS 


Send ANY OK with parameter value '0000' (see note 2). 


RQ3 


NOTE 1 : Other commands may be sent prior to the ADIVI_CLEAR_ALL_PIPE command. 
NOTE 2: This assumes that the HCI session initialization procedure has not resulted in any errors at the data 
link layer which would result in the incrementing of REG ERROR. 



5.5.2 Registry access 

Reference: TS 102 622 [1], clause 8.2. 
There are no new conformance requirements for the UICC for the referenced clause. 

5.5.3 Host and Gate discovery 

Reference: TS 102 622 [1], clause 8.3. 
There are no conformance requirements for the UICC for the referenced clause. 

5.5.4 Session initialization 
5.5.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.4. 



RQ1 


The Host shall perform session initialization only if no contactless transaction is pending at startup 
(e.g. after power up in full-power mode as defined in TS 102 613 [2]). 


RQ2 


If the data link layer specified in TS 102 613 [2] is being used, then after power up in full-power mode, 
the host shall perform session initialization. 


RQ3 


If the returned value of SESSIONJDENTITY equals the previous value stored in the host, the host shall 
stop the session initialization procedure. 


RQ4 


If the returned value of SESSIONJDENTITY does not equal the previous value stored in the host, the 
host needs to reinitialize and it requests the host controller to clear all pipes. 


R05 


In the context of R04, after performing any further initializations, the host generates a new session 
identity and stores its value and stores it in the host controller registry. 


NOTE: RQ1 is not tested in this clause, as the only circumstances where no contactless transaction is 

pending at startup which are defined after power up in full-power mode as defined in TS 102 613 [2], 
which is dealt with in RQ2. 



5.5.4.2 



Test case 1 : SESSIONJDENTITY not changed 



5.5.4.2.1 Test execution 

Run this test procedure in full power mode only. 
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5.5.4.2.2 Initial conditions 

• The host is not powered up. 



5.5.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HGS ^ HUT 


Power up host. 




2 


HUT^HCS 


Send ANY_SET_PARAMETER(SESSION_IDENTITY) on PIPE^ (see note 1). 




3 


HGS ^ HUT 


Send ANY OK. 




4 


HUT ^^ HGS 


Wait for any the HGI interface to be idle. 




5 


HGS ^ HUT 


Power down host. 




6 


HGS ^ HUT 


Power up host. 




7 


HUT ^ HGS 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE^ (see note 2). 


RQ2 


8 


HGS ^ HUT 


Send ANY OK with the same value of SESSION IDENTITY as in step 2. 




9 


HUT ^ HGS 


Do not send ADM GLEAR ALL PIPE or 

ANY SET PARAMETER(SESSION IDENTITY). 


RQ3 


NOTE 1 : Other commands may be sent prior to the ANY_SET_PARAMETER command (i.e. in order to let the 

HUT run the session initialization procedure). 
NOTE 2: Other commands may be sent prior to the ANY GET PARAIVIETER command. 



5.5.4.3 



Test case 2: SESSIONJDENTITY changed 



5.5.4.3.1 Test execution 

Run this test procedure in full power mode only. 

5.5.4.3.2 Initial conditions 

• The host is not powered up. 



5.5.4.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HGS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT ^ HGS 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE^ (see note 1). 


R02 


3 


HGS -^ HUT 


Send an allowed response code for the command. 




4 


HUT ^ HGS 


Send ADM_GLEAR_ALL_PIPE on PIPE.,; parameter value is not checked 
(see note 2) 


R04 


5 


HGS ^ HUT 


Send ANY OK. 




6 


HUT ^ HGS 


Send ANY_SET_PARAMETER(SESSION_IDENTITY) on PIPE^ with a 
different value from that previously used by the host (see note 3). 


R05 


7 


HGS ^ HUT 


Send ANY OK. 




NOTE 1 : Other commands may be sent prior to the ANYGETPARAIVIETER command. 
NOTE 2: Other commands may be sent prior to the ADIVI_GLEAR_ALL_PIPE command. 
NOTE 3: Other commands may be sent prior to the ANY SET PARAMETER command. 



5.5.5 Loop back testing 

5.5.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.5. 



A host shall accept the creation of a pipe to its loop back gate from any gate in another host. 



R01 



RQ2 



When a host receives the event EVT_POST_DATA on a pipe connected to its loop back gate, it shall 
send back the event EVT POST DATA with same data as received in the received EVT POST DATA. 



R03 



The loopback gate shall support at least all messages with size up to 250 bytes. 
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Test case 1 : pipe creation from host controller 



5.5.5.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Source Gjd values of: '00', '03', '05', '10', 'AA', 'FF. 

5.5.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|o as 
specified and destination G|p = G|p of loop bacl< gate. 




2 


HUT^HCS 


Send ANY OK (parameters are not checl<ed). 


RQ1 



5.5.5.3 



Test case 2: pipe creation from another host 



5.5.5.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Source Gjq values of: '00', '03', '05', '10', 'AA', 'FF'. 

5.5.5.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE[ is open. 



5.5.5.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source H|o equal to 
the H|Q contained in the host's WHITELIST, source G|d as specified and 
destination G|q = G^q of loop back gate. 




2 


HUT ^ HCS 


Send ANY_OK (parameters are not checked). 


RQ1 



5.5.5.4 Test case 3: processing of EVT_POST_DATA 

5.5.5.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• EVT_POST_DATA data sizes of: 1 byte, 100 bytes, 250 bytes. 

5.5.5.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 
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5.5.5.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send EVT_POST_DATA on PIPE_LOOP_BACK containing data of the 
specified size. 




2 


HUT^HCS 


Send EVT_POST_DATA on PIPE_LOOP_BACK containing the same data 
as in step 1 . 


RQ2, 
RQ3 



5.6 



Contactless card emulation 



5.6.1 Overview 

5.6.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.1. 



RQ1 For each card RF gate it wants to use, the host has one card application gate. 



RQ2 



For the contactless platform for card emulation mode the pipes to card RF gates shall be created, 
opened, closed and deleted by the host. 



RQ3 [The host shall not create more than one pipe to each RF gate. 



NOTE 1 : RQ1 and RQ2 are implicitly tested in clause 5.6.4. 
NOTE 2: RQ3 is a non-occurrence RQ. 



5.6.2 Void 

Reference: TS 102 622 [1], clause 9.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3 Gates 
5.6.3.1 Void 

Reference: TS 102 622 [1], clause 9.3.1. 
There are no conformance requirements for the UICC for the referenced clause. 



5.6.3.2 



Identity management gate 



5.6.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.2. 



RQ1 The host shall adhere to the access condition of RO for LOW POWER SUPPORT. 



NOTE: 



RQ1 is a non-occurrence RQ. 



5.6.3.3 



Card RF gates 



5.6.3.3.1 Overview 

Reference: TS 102 622 [1], clause 9.3.3.1. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.6.3.3.2 Commands 

5.6.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.2. 
There are no conformance requirements for the UlCC for the referenced clause. 

5.6.3.3.3 Events and subclauses 

5.6.3.3.3.1 Events 

5.6.3.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.3. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.3.3.2 EVT_SEND_DATA 
Reference: TS 102 622 [1], clause 9.3.3.3.1. 

There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.3.4 Registry and subclauses 

5.6.3.3.4.1 Registry 
Void. 

5.6.3.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.3.4.2 RF teclnnology type A 

5.6.3.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.41. 



RQ1 The host shall only set values of MODE of 'FF' and '02'. 



RQ2 



The host shall only set values of UID_REG with length 0, 4, 7 or 10. 



RQ3 



The host shall adhere to the access condition of WO for DID REG. 



R04 



The host shall only set values of CID_SUPPORT with value '00' or '01 ' 



R05 



The host shall adhere to the access condition of RO for CLT SUPPORT. 



R06 



The host shall only set values of DATARATE_MAX which codes maximum divisor supported with coding 
as specified in TS 102 622 [1]. 



NOTE: The conformance to ISO/IEC 14443-3 [4] and ISO/IEC 14443-4 [5] of the values written by the host is 
out of scope of the present document. 



5.6.3.3.4.2.2 Test case 1 : Type A registry values 

5.6.3.3.4.2.2.1 Test execution 

Run this test procedure in full power mode only. 
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5.6.3.3.4.2.2.2 Initial conditions 
• The host is not powered up. 

5.6.3.3.4.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^ ^ 
HCS 


Perform HCI session initialization, up to the point of setting a new value of 

SESSIONJDENTITY. 

The HCI session initialization shall meet the following requirements for registry 

parameters for type A: 

• For all writeable registry parameters (i.e. RW or WO), any values 
which the host sets shall be set in accordance with the RQs. 

• For all non-writeable registry parameters (i.e. RO), the host shall not 
attempt to write a value. 


RQ1, 
RQ2, 
RQS, 
RQ4, 
RQS, 
RQ6 



5.6.3.3.4.3 



RF technology type B 



5.6.3.3.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.2. 



RQ1 The host shall only set values of IVIQDE of 'FF' and '02'. 



RQ2 



The host shall only set values of PUPI_REG with length or 4. 



RQS 



The host shall adhere to the access condition of WO for PUP! REG. 



RQ4 



The host shall only set values of ATQB with length 4. 



RQS 



The host shall only set values of DATARATE_IVIAX which codes maximum bit rates supported with 
coding as specified in TS 102 622 [1]. 



NOTE: The conformance to ISO/IEC 1444S-S [4] and ISO/IEC 1444S-4 [5] of the values written by the host is 
out of scope of the present document. 



5.6.3.3.4.3.2 Test case 1 : Type B registry values 

5.6.3.3.4.3.2.1 Test execution 

Run this test procedure in full power mode only. 

5.6.3.3.4.3.2.2 Initial conditions 
• The host is not powered up. 

5.6.3.3.4.3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^ ^ 
HCS 


Perform HCI session initialization, up to the point of setting a new value of 

SESSIONJDENTITY. 

During the HCI session initialization, for all writeable registry parameters (i.e. 

RW or WO) for type B, any values which the host sets shall be set in 

accordance with the RQs. 


RQ1, 
RQ2, 
RQS, 
RQ4, 
RQS 
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RF technology type B' 



5.6.3.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.3. 
NOTE: Since this technology is not publicly disclosed, no conformance requirements have been established. 



5.6.3.3.4.5 



RF technology Type F (ISO18092 212 kbps/424 kbps card emulation only) 



5.6.3.3.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.4. 



RQ1 



The host shall only set values of MODE of 'FF' and '02'. 



R02 



The host shall adhere to the access condition of RO for SPEED CAP. 



R03 



The host shall adhere to the access condition of RO for CLT SUPPORT. 



5.6.3.3.4.5.2 Test case 1 : Type F registry values 

5.6.3.3.4.5.2.1 Test execution 

Run this test procedure in full power mode only. 

5.6.3.3.4.5.2.2 Initial conditions 
• The host is not powered up. 

5.6.3.3.4.5.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT ^ ^ HCS 


Perform HCI session initialization, up to the point of setting a new value of 

SESSIONJDENTITY. 

The HCI session initialization shall meet the following requirements for registry 

parameters for type F: 

• For all writeable registry parameters (i.e. RW), any values which the 
host sets shall be set in accordance with the RQs. 

• For all non-writeable registry parameters (i.e. RO), the host shall not 
attempt to write a value. 


R01, 
R02, 
RQS 



5.6.3.4 



Card application gates 



5.6.3.4.1 Overview 

Reference: TS 102 622 [1], clause 9.3.4.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.4.2 Commands 

5.6.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.2. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.6.3.4.3 Events and subclauses 

5.6.3.4.3.1 Events 

5.6.3.4.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3. 



RQ1 [Each card application gate shall support all events as listed. 



NOTE: This RQ is not tested in this clause, as it is tested in clause 5.6.4. 



5.6.3.4.3.2 EVT_FIELD_ON 

5.6.3.4.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.1. 

There are no conformance requirements for the UICC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 

5.6.3.4.3.3 EVT_CARD_DEACTIVATED 

5.6.3.4.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.2. 

There are no conformance requirements for the UICC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 

5.6.3.4.3.4 EVT_CARD_ACTIVATED 

5.6.3.4.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.3. 

There are no conformance requirements for the UICC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 

5.6.3.4.3.5 EVT_FIELD_OFF 

5.6.3.4.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.4. 

There are no conformance requirements for the UICC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 

5.6.3.4.3.6 EVT_SEND_DATA 

5.6.3.4.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.5. 



RQ1 On receiving EVT_SEND_DATA the host shall interpret the last parameter byte as RF error indicator. 



RQ2 I EVT_SEND_DATA shall be discarded by the host when the error indicator is set to '01 ' 



NOTE: These ROs are not tested in this clause, as they are tested in clause 5.6.4. 
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5.6.3.4.4 



Registry 



5.6.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.4. 



RQ1 



Registry parameters whicli are in tlie range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.4 Procedures 



5.6.4.1 



Use of contactless card application 



5.6.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 9.4.1, 9.3.4.3 and 9.3.4.3.5. 



RQ1 


9.4.1 


In the context of a valid contactless card application sequence as specified in TS 102 622 [1], the 
host shall reply to received C-APDUs contained in EVT_SEND_DATAs by sending the R-APDUs 
contained in EVT SEND DATAs to the card RF gate. 


RQ2 


9.4.1 


The host shall accept an EVT FIELD QFF which is received at any time during the sequence. 


RQS 


9.3.4.3 


Each card application gate shall support all events as listed. 


RQ4 


9.3.4.3.S 


Qn receiving EVT_SEND_DATA the host shall interpret the last parameter byte as RF error 
indicator. 


RQS 


9.3.4.3.S 


EVT SEND DATA shall be discarded by the host when the error indicator is set to '01 '. 


RQ6 


9.4.1 


In the context of a valid contactless card application sequence as specified in TS 102 622 [1], if 
the host receives an empty C-APDU, it shall reply to this with either an empty R-APDU or an R- 
APDU containing an error code. 


NQTE 1 : RQ2 is only partially tested since the reaction of the UICC upon reception of EVT_FIELD_QFF is not 

specified. 
NQTE 2: For RF error indicator = "no error", RQ4 is implicitly tested in all test cases. For RF error indicator = "error", 

RQS applies. 
NQTE 3: Development of test cases for RQS and RQ6 is FFS. 



5.6.4.1.2 



5.6.4.1.2.1 



Test case 1 : full power mode 



Test execution 



Run this test procedure in full power mode only. The test procedure shall be executed once for each of following 
parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 



5.6.4.1.2.2 



Initial conditions 



The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

HCI session initialization has been performed, the HCI interface is idle and the SWP interface is not 
DEACTIVATED. 

The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 
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5.6.4.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS-^HUT 


Send EVT FIELD ON event. 




2 


HCS->HUT 


Send EVT CARD ACTIVATED event. 




3 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




4 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ3 


5 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




6 


HCS->HUT 


Send EVT FIELD OFF event. 




7 


HCS^HUT 


Send EVT FIELD ON event. 




8 


HCS->HUT 


Send EVT CARD ACTIVATED event. 




9 


HCS-^HUT 


Send C-APDU with EVT SEND DATA event. 




10 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


11 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




12 


HCS^HUT 


Send EVT FIELD OFF event. 





5.6.4.1 .3 Test case 2: full power mode, no EVT_CARD_ACTIVATED and 

EVT_CARD_DEACTIVATED 

5.6.4.1.3.1 Test execution 

Run this test procedure in full power mode only. The test procedure shall be executed once for each of following 
parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 



5.6.4.1.3.2 



Initial conditions 



• The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

• HCI session initialization has been performed, the HCI interface is idle and the SWP interface is not 
DEACTIVATED. 

• The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 
5.6.4.1.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


Send EVT FIELD ON event. 




2 


HCS-^HUT 


Send C-APDU with EVT SEND DATA event. 




3 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ3 


4 


HCS^HUT 


Send EVT FIELD OFF event. 




5 


HCS^HUT 


Send EVT FIELD ON event. 




6 


HCS-^HUT 


Send EVT CARD ACTIVATED event. 




7 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




8 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


9 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




10 


HCS^HUT 


Send EVT FIELD OFF event. 
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Test case 3: sequence from DEACTIVATED state 



5.6.4.1.4.1 Test execution 

The test procedure shall be executed once for each of following parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 



5.6.4.1.4.2 



Initial conditions 



The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

For full power mode execution: SWP interface is deactivated. 

For low power mode execution: the Host is not powered up. 

At the end of the previous activation, the state of the card emulation pipe was open, and the MODE parameter 
was '02' (as set by the UICC). 



5.6.4.1.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For low power mode execution: power up Host. 




2 


HCS^HUT 


Activate SWP interface and establish SHDLC link 




3 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




4 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




5 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ3 


6 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




7 


HCS^HUT 


Send EVT FIELD OFF event. 




8 


HCS^HUT 


Send EVT FIELD ON event. 




9 


HCS-^HUT 


Send EVT CARD ACTIVATED event. 




10 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




11 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


12 


HCS-^HUT 


Send EVT CARD DEACTIVATED event. 




13 


HCS^HUT 


Send EVT FIELD OFF event. 





5.6.4.1 .5 Test case 4: sequence from DEACTIVATED state, no EVT_CARD_ACTIVATED 

or EVT_CARD_DEACTIVATED 

5.6.4.1.5.1 Test execution 

The test procedure shall be executed once for each of following parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 

5.6.4.1.5.2 Initial conditions 

• The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

• For full power mode execution: SWP interface is deactivated. 

• For low power mode execution: the Host is not powered up. 
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At the end of the previous activation, the state of the card emulation pipe was open, and the MODE parameter 
was '02' (as set by the UICC). 



5.6.4.1.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For low power mode execution: power up Host. 




2 


HCS^HUT 


Activate SWP interface and establish SHDLC link 




3 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




4 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ3 


5 


HCS^HUT 


Send EVT FIELD OFF event. 




6 


HCS^HUT 


Send EVT FIELD ON event. 




7 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




8 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




9 


HUT-»HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


10 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




11 


HCS^HUT 


Send EVT FIELD OFF event. 





5.6.4.1.6 



Test case 5: low power, power down instead of EVTFIELDOFF 



5.6.4.1.6.1 Test execution 

Run this test procedure in low power mode only. 

The test procedure shall be executed once for each of following parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 



5.6.4.1.6.2 



Initial conditions 



The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

The Host is not powered up. 

At the end of the previous activation, the state of the card emulation pipe was open, and the MODE parameter 
was '02' (as set by the UICC). 
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5.6.4.1.6.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS 


Power on Host. 




2 


HCS^HUT 


Activate SWP interface in low power mode and establisli 
SHDLC linl<. 




3 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




4 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




5 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ3 


6 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




7 


HCS 


Power down Host. 




8 


HCS 


Power on Host. 




9 


HCS-»HUT 


Activate SWP interface in low power mode and establish 
SHDLC link 




10 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




11 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




12 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


13 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




14 


HCS 


Power down Host. 





5.6.4.1.7 



Test case 6: EVT FIELD OFF after EVT FIELD ON / SWP interface activation 



5.6.4.1.7.1 Test execution 

The test procedure shall be executed once for each of following parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 



5.6.4.1.7.2 



Initial conditions 



The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

For full power mode execution: HCI session initialization has been performed and the HCI interface is idle. 

For low power mode execution: the Host is not powered up. 

The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 



5.6.4.1.7.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For full power mode execution: send EVT_FIELD_ON event. 
For low power mode execution: power up Host, activate SWP 
interface and establish SHDLC link. 




2 


HCS^HUT 


Send EVT FIELD OFF event. 




3 


HCS^HUT 


Send EVT FIELD ON event. 




4 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




5 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




6 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


R01, 
RQ2 


7 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




8 


HCS^HUT 


Send EVT FIELD OFF event. 
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Test case 7: EVT FIELD OFF after EVT CARD ACTIVATED 



5.6.4.1.8.1 Test execution 

The test procedure shall be executed once for each of following parameters. 

Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

Type B (if supported). 



5.6.4.1.8.2 



Initial conditions 



The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

For full power mode execution: HCI session initialization has been performed and the HCI interface is idle. 

For low power mode execution: the Host is not powered up. 

The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 



5.6.4.1.8.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For full power mode execution: send EVT_FIELD_ON event. 
For low power mode execution: power up Host, activate SWP 
interface and establish SHDLC link. 




2 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




3 


HCS^HUT 


Send EVT FIELD OFF event. 




4 


HCS^HUT 


Send EVT FIELD ON event. 




5 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




6 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




7 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


R01, 
RQ2 


8 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




9 


HCS^HUT 


Send EVT FIELD OFF event. 





5.6.4.1.9 



Test case 8: EVT FIELD OFF after EVT SEND DATA 



5.6.4.1.9.1 Test execution 

The test procedure shall be executed once for each of following parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 

5.6.4.1.9.2 Initial conditions 

• The host controller simulator is configured to support only the RF gate for the RF technology specified in the 
Test execution clause. 

• For full power mode execution: HCI session initialization has been performed and the HCI interface is idle. 

• For low power mode execution: the Host is not powered up. 

• The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 
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5.6.4.1.9.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For full power mode execution: send EVT_FIELD_ON event. 
For low power mode execution: power up Host, activate SWP 
interface and establish SHDLC link. 




2 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




3 


HCS^HUT 


Send C-APDU with EVT SEND DATA event . 




4 


HCS^HUT 


Send EVT_FIELD_OFF event as soon as possible after event in 
step 3 (see note). 




5 


HCS^HUT 


Send EVT FIELD ON event after delay of at least 1 00 ms. 




6 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




7 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




8 


HUT-^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


9 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




10 


HCS^HUT 


Send EVT FIELD OFF event. 




NOTE: UICC may send R-APDU with EVT SEND DATA which may overlap with EVT FIELD OFF. 



5.6.4.1.10 



Test case 9: multiple open card gates 



5.6.4.1.10.1 Test execution 

The test procedure shall be executed once for each of following parameters. 

• Type A (if supported, and the UICC sets a value of SAK indicating support of ISO/IEC 14443-4 [5]). 

• Type B (if supported). 

5.6.4.1.10.2 Initial conditions 

• The host controller simulator is configured to support RF gates for all RF technologies. 

• For full power mode execution: HCI session initialization has been performed and the HCI interface is idle. 

• For low power mode execution: the Host is not powered up. 

• The UICC has opened the card emulation pipe specified in test execution clause and set the MODE parameter 
to '02'. 

• At least one further card application gate is open. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For full power mode execution: send EVT_FIELD_ON event to 
the open card application gate with the lowest Gid. 
For low power mode execution: power up Host, activate SWP 
interface and establish SHDLC link. 




2 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




3 


HCS-^HUT 


Send C-APDU with EVT SEND DATA event. 




4 


HUT-^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ3 


5 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




6 


HCS^HUT 


Send EVTFIELDOFF event to the open card application gate 
with the lowest Gid. 




7 


HCS^HUT 


Send EVT_FIELD_ON event to the open card application gate 
with the lowest Gid. 




8 


HCS-^HUT 


Send EVT CARD ACTIVATED event. 




9 


HCS^HUT 


Send C-APDU with EVT SEND DATA event. 




10 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


11 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




12 


HCS^HUT 


Send EVT_FIELD_OFF event to the open card application gate 
used during transaction. 




13 


HCS->HUT 


Send EVTFIELDON event to the open card application gate 
with the lowest Gid. 




14 


HCS^HUT 


Send EVT CARD ACTIVATED event. 




15 


HCS->HUT 


Send C-APDU with EVT SEND DATA event. 




16 


HUT^HCS 


Send R-APDU with EVT_SEND_DATA event. 


RQ1, 
RQ2 


17 


HCS^HUT 


Send EVT CARD DEACTIVATED event. 




18 


HCS->HUT 


Send EVTFIELDOFF event to the open card application gate 
used during transaction. 





5.6.4.2 



Non ISO/IEC 14443-4 type A 



5.6.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 9.4.2 and clause 9.3.4.3. 



RQ1 


9.4.2 


In the context of a valid contactless card application sequence as specified in TS 
102 622 [1], the host shall support communications using the CLT mode as defined in 
TS 102 613 [2]. 


RQ2 


9.4.2 


The host shall accept an EVT_FIELD_OFF which is received at any time during the 
sequence. 


RQ3 


9.3.4.3 


Each card application gate shall support all events as listed (see note 1). 


NOTE 1 : In the context of a non ISO/IEC 1 4443-4 [5] type A transaction only EVT FIELD ON and 

EVT_FIELD_OFF are used. 
NOTE 2: RQ2 is only partially tested since the reaction of the UICC upon reception of EVTFIELDOFF is not 

specified. 



5.6.4.2.2 



Test case 1 : full power mode 



5.6.4.2.2.1 Test execution 

Run this test procedure in full power mode only. 
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5.6.4.2.2.2 



Initial conditions 



The host controller simulator is configured to support only the Type A card RF gate, with CLT_SUPPORT set 
to '01' (CLT supported). 

HCI session initialization has been performed and the HCI interface is idle. 

The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 



5.6.4.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


Send EVT FIELD ON event. 




2 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD and a 
valid command (see note) for one of the RF protocols supported by the 
UICC in the DATA FIELD. 




3 


HUT^HCS 


Respond CLT frame with CLT CIVID field set to 00000 and at least 1 byte 
of data in the CLT PAYLOAD field. 


RQ1 


4 


HCS^HUT 


Send CLT frame with CLT_CIVID field set to 00000 and a valid command 
(see note) for one of the RF protocols supported by the UICC in the 
DATA FIELD. 




5 


HUT^HCS 


Respond CLT frame with CLT CIVID field set to 00000. 


RQ1 


6 


HCS^HUT 


Send EVT FIELD OFF event. 




7 


HCS^HUT 


Send EVT FIELD ON event. 




8 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD and a 
valid command (see note) for one of the RF protocols supported by the 
UICC in the DATA FIELD. 




9 


HUT^HCS 


Respond CLT frame with CLT CIVID field set to 00000 and at least 1 byte 
of data in the CLT PAYLOAD field. 


RQ1, 
RQ2, 
RQ3 


10 


HCS^HUT 


Send EVT FIELD OFF event. 




NOTE: This command shall be chosen in a way that the UICC responds data with respect to RF, and without 
requesting a transition to "HALT" or "IDLE" state as per ISO/IEC 14443-3 [4]. 



5.6.4.2.3 

5.6.4.2.3.1 
Void. 

5.6.4.2.3.2 



Test case 2: sequence from DEACTIVATED state 
Test execution 

Initial conditions 



• The host controller simulator is configured to support only the Type A card RF gate, with CLT_SUPPORT set 
to '01' (CLT supported). 

• For full power mode execution: SWP interface is deactivated. 

• For low power mode execution: the Host is not powered up. 

• The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 
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5.6.4.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For low power mode execution: power up Host. 




2 


HCS^HUT 


Activate SWP interface and establish SHDLC link. 




3 


HCS^HUT 


Send CLT frame with CL_PROTO_INF{A) in the ADMIN_FIELD and 
a valid command (see note) for one of the RF protocols supported by 
the UICC in the DATA FIELD. 




4 


HUT-^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 1 
byte of data in the CLT PAYLOAD field. 


RQ1 


5 


HCS^HUT 


Send CLT frame with CLT_CMD field set to 00000 and a valid 
command (see note) for one of the RF protocols supported by the 
UICC in the DATA FIELD. 




6 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000. 


RQ1 


7 


HCS^HUT 


Send EVT FIELD OFF event. 




8 


HCS^HUT 


Send EVT FIELD ON event. 




9 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD and 
a valid command (see note) for one of the RF protocols supported by 
the UICC in the DATA FIELD. 




10 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 1 
byte of data in the CLT PAYLOAD field. 


RQ1, 
RQ2, 
RQ3 


11 


HCS^HUT 


Send EVT FIELD OFF event. 




NOTE: This command shall be chosen in a way that the UICC responds data with respect to RF, and without 
requesting a transition to "HALT" or "IDLE" state as per ISO/IEC 14443-3 [4]. 



5.6.4.2.4 



Test case 3: low power mode, power down instead EVTFIELDOFF 



5.6.4.2.4.1 Test execution 

Run this test procedure in low power mode only. 

5.6.4.2.4.2 Initial conditions 

• The host controller simulator is configured to support only the Type A card RF gate, with CLT_SUPPORT set 
to '01' (CLT supported). 

• The Host is not powered up. 

• At the end of the previous activation, the state of the card emulation pipe was open, and the MODE parameter 
was '02' (as set by the UICC). 
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5.6.4.2.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS 


Power on Host. 




2 


HCS^HUT 


Activate SWP interface in low power mode and establish SHDLC 
link. 




3 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD 
and a valid command (see note) for one of the RF protocols 
supported by the UICC in the DATA FIELD. 




4 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 
1 byte of data in the CLT PAYLOAD field. 


R01 


5 


HCS^HUT 


Send CLT frame with CLT_CIVID field set to 00000 and a valid 
command (see note) for one of the RF protocols supported by the 
UICC in the DATA FIELD. 




6 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000. 


RQ1 


7 


HCS 


Power down Host. 




8 


HCS 


Power on Host 




9 


HCS^HUT 


Activate SWP interface in low power mode and establish SHDLC 
link 




10 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD 
and a valid command (see note) for one of the RF protocols 
supported by the UICC in the DATA FIELD. 




11 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 
1 byte of data in the CLT PAYLOAD field. 


RQ1, 
RQ2, 
R03 


12 


HCS^HUT 


Send EVT FIELD OFF event. 




NOTE: This command shall be chosen in a way that the UICC responds data with respect to RF, and without 
requesting a transition to "HALT" or "IDLE" state as per ISO/IEC 14443-3 [4]. 



5.6.4.2.5 

5.6.4.2.5.1 
Void. 

5.6.4.2.5.2 



Test case 4: EVT FIELD OFF after EVT FIELD ON / SWP interface activation 



Test execution 



Initial conditions 



• The host controller simulator is configured to support only the Type A card RF gate, with CLT_SUPPORT set 
to '01' (CLT supported). 

• For full power mode execution: HCI session initialization has been performed and the HCI interface is idle. 

• For low power mode execution: the Host is not powered up. 

• The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 



5.6.4.2.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For full power mode execution: send EVT_FIELD_ON event. 
For low power mode execution: power up Host, activate SWP 
interface and establish SHDLC link. 




2 


HCS^HUT 


Send EVT FIELD OFF event. 




3 


HCS^HUT 


Send EVT FIELD ON event. 




4 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD and 
a valid command (see note) for one of the RF protocols supported by 
the UICC in the DATA FIELD. 




5 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 1 
byte of data in the CLT PAYLOAD field. 


RQ1 


6 


HCS^HUT 


Send EVT FIELD OFF event. 




NOTE: This command shall be chosen in a way that the UICC responds data with respect to RF, and without 
requesting a transition to "HALT" or "IDLE" state as per ISO/IEC 14443-3 [4]. 
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5.6.4.2.6 

5.6.4.2.6.1 
Void. 

5.6.4.2.6.2 



Test case 5: EVTFIELDOFF during CLT frames exchange 
Test execution 

Initial conditions 



• The host controller simulator is configured to support only the Type A card RF gate, with CLT_SUPPORT set 
to '01' (CLT supported). 

• For full power mode execution: HCI session initialization has been performed and the HCI interface is idle. 

• For low power mode execution: the Host is not powered up. 

• The UICC has opened the card emulation pipe and set the MODE parameter to '02'. 



5.6.4.2.6.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For full power mode execution: send EVTFIELDON event. 
For low power mode execution: power up Host, activate SWP 
interface and establish SHDLC link. 




2 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD 
and a valid command (see note) for one of the RF protocols 
supported by the UICC in the DATA FIELD. 




3 


HUT-^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 
1 byte of data in the CLT PAYLOAD field. 


RQ1 


4 


HCS^HUT 


Send CLT frame with CLT_CMD field set to 00000 and a valid 
command (see note 1 ) for one of the RF protocols supported by 
the UICC in the DATA FIELD. 




5 


HCS-^HUT 


Send EVT FIELD OFF event (see note 2). 


RQ1 


6 


HCS-^HUT 


Send EVT FIELD ON event after delay of at least 100 ms. 




7 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD 
and a valid command (see note 1 ) for one of the RF protocols 
supported by the UICC in the DATA FIELD. 




8 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 
1 byte of data in the CLT PAYLOAD field. 


RQ1, 
RQ2, 
RQ3 


9 


HCS-^HUT 


Send EVT FIELD OFF event. 




NOTE 1 : This command shall be chosen in a way, that the UICC responds data with respect to RF, and without 

requesting a transition to "HALT" or "IDLE" state as per ISO/IEC 14443-3 [4]. 
NOTE 2: UICC may send CLT response which may overlap with EVT_FIELD_OFF. 



5.6.4.2.7 

5.6.4.2.7.1 
Void. 

5.6.4.2.7.2 



Test case 6: multiple open card gates 
Test execution 

Initial conditions 



The host controller simulator is configured to support RF gates for all RF technologies, with CLT_SUPPORT 
for the Type A card RF gate set to '01' (CLT supported). 

For full power mode execution: HCI session initialization has been performed and the HCI interface is idle. 

For low power mode execution: the Host is not powered up. 

The UICC has opened the card emulation pipe specified in test execution clause and set the MODE parameter 
to '02'. 

At least one further card application gate is open. 
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5.6.4.2.7.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^HUT 


For full power mode execution: send EVT_FIELD_ON event to the open card 
application gate with the lowest Gid. 

For low power mode execution: power up Host, activate SWP interface and 
establish SHDLC link. 




2 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD and a valid 
command (see note) for one of the RF protocols supported by the UICC in the 
DATA FIELD. 




3 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 1 byte of 
data in the CLT PAYLOAD field. 


R01 


4 


HCS^HUT 


Send CLT frame with CLT_CIVID field set to 00000 and a valid command (see 
note) for one of the RF protocols supported by the UICC in the DATA FIELD. 




5 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000. 


R01 


6 


HCS^HUT 


Send EVT_FIELD_OFF event to the open card application gate with the lowest 
Gid. 




7 


HCS^HUT 


Send EVT_FIELD_ON event to the open card application gate with the lowest 
Gid. 




8 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD and a valid 
command (see note) for one of the RF protocols supported by the UICC in the 
DATA FIELD. 




9 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 1 byte of 
data in the CLT PAYLOAD field. 


R01, 
R02, 
R03 


10 


HCS^HUT 


Send EVTFIELDOFF event to the open card application gate used during 
transaction. 




11 


HCS^HUT 


Send EVTFIELDON event to the open card application gate with the lowest 
Gid. 




12 


HCS^HUT 


Send CLT frame with CL_PROTO_INF(A) in the ADMIN_FIELD and a valid 
command (see note) for one of the RF protocols supported by the UICC in the 
DATA FIELD. 




13 


HUT^HCS 


Respond CLT frame with CLT CMD field set to 00000 and at least 1 byte of 
data in the CLT PAYLOAD field. 


R01, 
R02, 
R03 


14 


HCS^HUT 


Send EVT_FIELD_OFF event to the open card application gate used during 
transaction. 




NOTE: This command shall be chosen in a way, that the UICC responds data with respect to RF, and without 
requesting a transition to "HALT" or "IDLE" state as per ISO/IEC 14443-3 [4]. 



5.6.4.3 



Type B' RF technology 



5.6.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.3. 

NOTE: Since this technology is not publicly disclosed, no conformance requirements have been established. 
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5.6.4.4 Type F RF technology 

5.6.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.4. 



RQ1 



In the context of a valid contactless card application sequence as specified in TS 102 622 [1], and In case 
SWP as defined in TS 102 613 [2] is used as a data link layer, the initialization data exchange is performed 
using CLT as defined in TS 1 02 61 3 [2] 



RQ2 



In the context of a valid contactless card application sequence as specified in TS 102 622 [1], the host shall 
reply to received ISO/IEC 18092 [3] 212 kbps/424 kbps frames contained in EVT_SEND_DATAs by sending 
the ISO/IEC 18092 [3] 212 kbps/424 kbps frames contained in EVT_SEND_DATAs to the card RF gate. 



RQ3 [The host shall accept an EVT_FIELD_OFF which is received at any time during the sequence. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.4.5 Update RF technology settings 
5.6.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.5. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.4.6 Identity check 

5.6.4.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.6. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7 Contactless reader 

5.7.1 Overview 

5.7.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.1. 



RQ1 For each reader RF gate it wants to use, the host has one reader application gate. 



RQ2 [The host shall not create more than one pipe to each reader RF gate. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2 Reader RF gates 



5.7.2.1 Overview 

Reference: TS 102 622 [1], clause 10.2.1. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.7.2.2 Command 

5.7.2.2.1 WR_XCHG_DATA 

5.7.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.2.1. 



RQ1 



The host shall have at least one byte in parameter of WR_XCHG_DATA. 



RQ2 



In the CTR field of WR XCHG DATA, bit b8 to b6 shall set to 0. 



RQ3 



In the CTR field of WR_XCHG_DATA, if bit b5 is set to one, the host shall use timeout value 
between and 14. 



RQ4 



On receiving value '00' of RF error indicator, the host shall interpret the received data having no 
error. 



RQ5 



On receiving value '01' of RF error indicator, the host shall interpret the received data having an 
error. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.3 Registries 

5.7.2.3.1 Type A reader RF gate 

5.7.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.1. 



RQ1 The host shall adhere to the access condition of RO for DID. 



R02 



The host shall adhere to the access condition of RO for ATQA. 



R03 



The host shall adhere to the access condition of RO for APPLICATION DATA. 



R04 



The host shall adhere to the access condition of RO for SAK. 



R05 



The host shall adhere to the access condition of RO for FWI, SFGT. 



R06 [The host shall only set values of DATARATE_MAX as specified in TS 1 02 622 [1 ] 



NOTE 1 : Conformance to ISO/IEC 1 4443-3 [4] and ISO/IEC 1 4443-4 [5] of the values written by the host is 

out of scope of the present document. 
NOTE 2: Development of test cases for above listed RQs is FFS. 



5.7.2.3.2 Type B reader RF gate 

5.7.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.2. 



R01 The host shall adhere to the access condition of RO for PUPI. 



R02 



The host shall adhere to the access condition of RO for APPICATION DATA. 



R03 



The host shall adhere to the access condition of RO for HIGHER LAYER RESPONSE. 



NOTE 1 : Conformance to ISO/IEC 1 4443-3 [4] and ISO/IEC 1 4443-4 [5] of the values written by the host is 

out of scope of the present document. 
NOTE 2: Development of test cases for above listed RQs is FFS. 



5.7.2.4 Events and subclauses 

5.7.2.4.1 Events 

5.7.2.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.7.2.4.2 EVT_READER_REQUESTED 

5.7.2.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.1. 



RQ1 [When the host sends EVT_READER_REQUESTED. it shall contain no parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.4.3 EVT_END_OPERATION 

5.7.2.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.2.5 Responses 

5.7.2.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.5. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.3 Reader application gates 

5.7.3.1 Overview 

Reference: TS 102 622 [1], clause 10.3.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.3.2 Command 

5.7.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.3.3 Registry 

5.7.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.3. 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ1 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.7.3.4 Events and subclauses 

5.7.3.4.1 Events 

5.7.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4. 



RQ1 [The reader application gates support the event name EVT_TARGET_DISCOVERED. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.3.4.2 EVT_TARGET_DISCOVERED 

5.7.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.4 Procedures 

5.7.4.1 Use of contactless reader application 

5.7.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.4.1. 



RQ1 



The host shall send the EVT_READER_REQUESTED event on a single pipe only. 



RQ2 



In the context of a valid contactless reader application sequence as specified in TS 102 622 [1], the host 
shall only send WR_XCHG_DATA commands after receiving an EVT_TARGET_DISCOVERED event 
which indicates that there is a single target in the reader field. 



RQS 



In the context of a valid contactless reader application sequence as specified in TS 102 622 [1], if the 
host receives an EVT_TARGET_DISGOVERED event which indicates that there are several targets in 
the field, the host shall not send WR XGHG DATA commands. 



RQ4 



The host shall send the EVT_END_OPERATION event on a single pipe only. 



RQS 



In the context of a valid contactless reader application sequence as specified in TS 102 622 [1], if the 
host sends an EVT_END_OPERATION event, it shall not send further WR_XCHG_DATA commands 
until it has received a further EVT TARGET DISCOVERED event. 



RQ6 



In the context of a valid contactless reader application sequence as specified in TS 102 622 [1], the host 
shall send the EVT END OPERATION. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8 Connectivity 

5.8.1 Overview 

Reference: TS 102 622 [1], clause 11.1. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.2 Connectivity gate and subclauses 
5.8.2.1 Connectivity gate 

Reference: TS 102 622 [1], clause 11.2. 
There are no conformance requirements for the Host for the referenced clause. 
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5.8.2.2 Commands 

5.8.2.2.1 PRO_HOST_REQUEST 

5.8.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.1.1. 



RQ1 



The Host shall not try to interact with any other host except the host controller before receiving the 
response of PRO_HOST_REQUEST. 



RQ2 



The Host shall not try to interact with another host if the response of PRO_HOST_REQUEST is not 
ANY OK. 



RQ3 



The Host shall not try to interact with the host after the expired activation duration time. 



RQ4 



The Host shall not put the host controller or the terminal host in the list of host identifiers. 



RQ5 



When the Host sends a PRO_HOST_REQUEST, it shall use at least 3 bytes parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.2.3 Events and subclauses 

5.8.2.3.1 Events 

Reference: TS 102 622 [1], clause 11.2.2. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.2.3.2 EVT_CONNECTIVITY 

5.8.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.1. 



RQ1 [When the Host sends EVT_CONNECTIVITY, it shall contain no parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.2.3.3 Void 

Reference: TS 102 622 [1], clause 11.2.2.2. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.2.3.4 EVT_OPERATION_ENDED 

5.8.2.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.3. 



R01 When the Host send EVT_OPERATION_ENDED. it shall not contain parameters. 



R02 [The Host shall only EVT_OPERATION_ENDED in the context of a PRO_HOST_REOUEST command. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.8.2.3.5 EVT_TRANSACTION 

5.8.2.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.4. 



RQ1 



When the Host sends the EVT_TRANSACTION, it shall use BER-TLV parameters as defined in 
TS102 622[1]. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.2.4 Registry 

5.8.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.3. 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ1 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.3 Connectivity application gate and subclauses 

5.8.3.1 Connectivity application gate 
5.8.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.3.2 Commands 

5.8.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.1. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.3.3 Events and subclauses 
5.8.3.3.1 Events 

5.8.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2. 
There are no conformance requirements for the Host for the referenced clause. 
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5.8.3.3.2 EVT_STANDBY 

5.8.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2.1. 



RQ1 



When the Host receives the EVT_STANDBY, it shall stop any ongoing communication with the other 
hosts and the host controller within 100 ms. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.3.4 Registry 

5.8.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.3. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.4 Procedures 

5.8.4.1 Use of connectivity gate 

Reference: TS 102 622 [1], clause 11.4.1. 
There are no conformance requirements for the Host for the referenced clause. 
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Annex A (informative): 

Core specification version information 

Unless otherwise specified, the versions of TS 102 622 [1] from which conformance requirements have been extracted 
are as follows: 



Release 


Latest version from which conformance requirements have been extracted 


7 


V7.10.0 


8 


V8.4.0 


9 


V9.4.0 
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Annex B (informative): 
Change history 



This annex lists all Changes Requests (CR) applied to the present document. 
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